Re: [media-types] [Netconf] request review of media type application/yang-data+xml

[Andy Bierman <[e-mail]>]

On Fri, Jul 1, 2016 at 1:31 AM, Martin Bjorklund <[e-mail]> wrote:

> Andy Bierman <[e-mail]> wrote:
> > removing all text except the fragment identifier issue....
> >
> > According to RFC 7303, sec. 5, any usage of +xml requires implementation
> of
> > the XPointerFramework
> > https://www.w3.org/TR/2003/REC-xptr-framework-20030325/
>
> Actually, it says SHOULD:
>
>    If [XPointerFramework] and [XPointerElement] are inappropriate for
>    some XML-based media type, it SHOULD NOT follow the naming convention
>    '+xml'.
>
> > RESTCONF "fragments" are sub-trees within the YANG data structures.
> > These are accessed by the request URI path and the "fields" query
> parameter.
> > XPointer is rather complex and completely redundant for RESTCONF.
>
> I'm not sure the "element()" scheme is complex to implement.  The
> "fields" query parameter probably takes more effort to implement.
>
> Note though that the "fields" query parameter is more expressive than
> the "element()" scheme, and it works with other encodings than XML.
> *if* we were to use XPointer instead of "fields", what would we do for
> JSON?
>


IMO it would be a bad idea to have media-specific filtering.
YANG provides an abstraction of datastore contents which we want to be
independent
of the various query response representations found in protocol messages.

We are filtering on the datastore contents, not on the XML representation
of individual query responses.



> > So do we have to add text that a RESTCONF server MUST implement the
> > "element"
> > scheme?
>
> If this indeed is to be interpreted as a requirement, I'd rather not
> use the "+xml" name.
>
>

Are there any objections to dropping the +xml?

What about dropping +json as well?

http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml

This page implies our "fields" parameter MUST NOT overlap with XPointer.



> /martin
>


Andy