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

From: Martin Bjorklund <[email-masked]>
Date: Fri, 01 Jul 2016 10:31:13 +0200 (CEST)

Andy Bierman <[email-masked]> 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? 

> 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.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Jul 2016 09:57:42 -0700

> *if* we were to use XPointer instead of "fields", what would we do for

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.

> If this indeed is to be interpreted as a requirement, I'd rather not

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

---

From: Sean Leonard <[email-masked]>
Date: Wed, 6 Jul 2016 12:06:47 -0700

On 7/5/2016 9:57 AM, Andy Bierman wrote:
> [...]

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