Re: [netconf] restconf collections

[Martin Björklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> [Update: a spinoff team has formed and is working on two I-D’s]
> 
> One issue has come up, regarding the encoding when GET returns a list
> or leaf-leaf.
> 
> Generally, in RFC 8040, GET returns an instance of the targeted
> resource.  This continues to be possible with JSON, as the
> list/leaf-list is a JSON array, but no array-equivalent exists with
> XML.
> 
> This is likely why Section 4.3 states "More than one element MUST NOT
> be returned for XML encoding”, though this statement never needed to
> be said, as there is no case where more than one element would be
> returned anyway!
> 
> This intent of this email is to discuss changing that statement in
> 4.3, that is, to allow more than one element to be returned for the
> XML encoding.
> 
> Following are what I hope the WG can agree on being valid responses:
> 
> ===== JSON =====
> 
> 
>  REQUEST
> 
>     GET /restconf/data/example-jukebox:jukebox/library/artist?where=<expr>
>     Host: example.com
>     Accept: application/yang-data+json
> 
> 
>  RESPONSE-1 (list exists, but no matching content)
> 
>     HTTP/1.1 204 No Content
>     Date: Thu, 26 Jan 2017 20:56:30 GMT
>     Server: example-server
> 
> 
>  RESPONSE-2 (matching content)
> 
>     HTTP/1.1 200 OK
>     Date: Thu, 26 Jan 2017 20:56:30 GMT
>     Server: example-server
>     Content-Type: application/yang-data+json
> 
>     {
>       "example-jukebox:artist”: [
>         {
>          “name”: "Foo Fighters”,
>           “album”: {
>             “name”: "One by One”,
>             “year”: 2012
>           }
> 
>         },
>         {
>           “name”: "Nick Cave and the Bad Seeds”,
>           “album”: {
>             “name”: "Tender Pre”,
>             “year”: 1988
>           }
>         }
>       ]
>     }
> 
> 
> 
> ===== XML =====
> 
> 
>   REQUEST
> 
>     GET /restconf/data/example-jukebox:jukebox/library/artist?where=<expr>
>     Host: example.com
>     Accept: application/yang-data+xml
> 
> 
>   RESPONSE-1 (list exists, but no matching content)
> 
>     HTTP/1.1 204 No Content
>     Date: Thu, 26 Jan 2017 20:56:30 GMT
>     Server: example-server
> 
> 
>   RESPONSE-2 (matching content)
> 
>     HTTP/1.1 200 OK
>     Date: Thu, 26 Jan 2017 20:56:30 GMT
>     Server: example-server
>     Content-Type: application/yang-data+xml
> 
>     <artist xmlns="https://example.com/ns/example-jukebox">
>       <name>Foo Fighters</name>
>       <album>
>         <name>One by One</name>
>         <year>2012</year>
>       </album>
>     </artist>
>     <artist xmlns="https://example.com/ns/example-jukebox">
>       <name>Nick Cave and the Bad Seeds</name>
>       <album>
>         <name>Tender Prey</name>
>         <year>1988</year>
>       </album>
>     </artist>
> 
> 
> 
> Thoughts?  If no objection, we will proceed as per above.
> 
> PS: I am aware, of course, of the pseudo-parent element (“collection”)
> defined in in draft-ietf-netconf-restconf-collection.  The hope is to
> avoid needing to introduce a pseudo element, as the above seems
> simpler, more consistent, and without issues, other than requiring
> that statement in Section 4.3 to be rescinded.

This is not a good proposal, since the result is not a valid XML
document.  An XML document has exactly one root element.

Also, the media types used in the examples are misleading.  The
example reply doesn't match the media type
"application/yang-data+json" (same for xml).

I suggest you define new media types and a "collection" root
element; or keep the media types and define "collection" in a YANG
module as:

  anydata collection;


/martin