Re: [netconf] Guidelines for YANG anyxml/anydata statements in RFC8040 (Restconf)

[Kent Watsen <[e-mail]>]

Hi Henning,


> I have some trouble with the anyxml/anydata YANG statements in
> Restconf... to be more precise in a Restconf-server that accepts both
> XML and JSON transport encoding.

Is the server bound to an application that can provide supplemental schema for the anyxml/anydata schema?


> The anydata issue is that there are some "data resources" that have
> the same XML transport encoding but different JSON encoding. Which
> means I cannot "guess" the YANG schema of incoming XML data for an
> anyxml statement.

Is the issue *only* with incoming XML data?  That is, is incoming JSON data always mappable to conforming XML data?  I think that this almost true, but my spider-sense is tingling.  Something beyond the XML-encoding’s [seemingly unnecessary] requirement that list keys are encoded first and in order...


> If I read RFC 7950 and 7951 correctly, then a (as an example)
> leaf-list with a single entry has the same encoding in XML as a leaf
> of the same name... but not in JSON. Same is true for a list with one
> element and a container.

Can the server mandate some limitations/conventions/annotations that would enable transcoding?    For instance, could the server require that "xsi:schemaLocation” be set in order to grok incoming XML ‘any’ data?    Or, alternately, define a proprietary XML-attriibute where needed?

If not, likely all that can be done is to treat the XML ‘any’ data as an opaque blob.   FWIW, this is in effect what RFC 8572 does by using “binary” instead of “anydata” for its “configuration” leaf:

          leaf configuration {
            type binary;
            description
              "Any configuration known to the device.  The use of
               the 'binary' type enables content (e.g., XML) to be
               embedded into a JSON document.  The exact encoding
               of the content, as with the scripts, is vendor
               specific.";
          }

          Note: the middle sentence should’ve been written: "The use of the
                   'binary' type enables content (e.g., XML) to be embedded
                    into a document with an alternate encoding (e.g., JSON).


> The problem with anyxml is the same and worse... RFC 7951 section 5.6
> demands transporting the data encoded in JSON (and not in a string
> that contains the XML data), but does not define how to encode the XML
> data into JSON and the other way around.

Does “anyxml” have to be supported, given that it’s effectively (albeit not yet officially) deprecated?


> Are there any guidelines/best-practices for this problem?

Not yet that I’m aware of, but it might make a nice I-D if we can come up with some.


Kent // contributor