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

[Sean Leonard <[e-mail]>]

On 7/5/2016 9:57 AM, Andy Bierman wrote:
> [...]
>
> 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.

I believe that +xml and +json should stay on.

I have not seen the XPointer issue actually trip up a registration. 
(However, the XPointer thing is kind of new, being in RFC 7303...) The 
+xml is important because it signals to intermediaries that they can do 
XML analysis. This strikes me as more important than the fragment stuff, 
and would in any event be a justification to override the "SHOULD NOT 
+xml" language. The media type reviewer should say something about this...

I guess the bottom line for me is: are applications actually going to 
use fragment identifiers--is there a commercial use case? Or is this 
just pontificating about stuff that won't actually get implemented?

If it's a real use case, do you want a uniform fragment identifier 
syntax across data syntaxes, so that #foo refers to the same semantic 
construct across +xml, +json, +cbor, etc.? And if so, why? (I get that 
"YANG provides an abstraction of datastore contents which we want to be 
independent of the various query response representations"; but, the 
YANG processors are representation-aware...so the mere fact that 
#xpointer-fragment-form and #json-fragment-form are different from each 
other, does not strike me as a big deal. The YANG processors know about 
XML vs. JSON so they have to do XML vs. JSON-specific things anyway.)

Sean