Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> On Fri, Jan 23, 2015 at 2:14 AM, Ladislav Lhotka <[e-mail]> wrote:
> > Juergen Schoenwaelder <[e-mail]> writes:
> >
> >> On Thu, Jan 22, 2015 at 03:57:36PM -0800, Andy Bierman wrote:
> >>> On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman <[e-mail]> wrote:
> >>> > On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder
> >>> > <[e-mail]> wrote:
> >>> >> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote:
> >>> >>> Hi,
> >>> >>>
> >>> >>> Juergen Schoenwaelder <[e-mail]> wrote:
> >>> >>> > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04.
> >>> >>>
> >>> >>> I don't think Y34-04 is sufficient.  If I understand Y34-04 (add
> >>> >>> 'root) correctly, the difference between it and Y34-02 (add 'anydata')
> >>> >>> is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as
> >>> >>> 'anydata' with the constraint that it only can hande top-level nodes.
> >>> >>>
> >>> >>> As an example of why this is not sufficient, YANG PATCH uses anyxml
> >>> >>> with non-top-level nodes.  It would not be possible to use 'root' in
> >>> >>> this case.  'anydata' would be a better match.
> >>> >>>
> >>> >>
> >>> >> Andy,
> >>> >>
> >>> >> can you please respond to this since you created Y34-04? I now hear
> >>> >> two people in favour of Y34-02 and we had this back in July 2014:
> >>> >>
> >>> >>    2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out
> >>> >>    a concrete proposal.
> >>> >>
> >>> >> So is the main delta of Y34-04 compared to Y34-02 (i) the additional
> >>> >> text (the three list items) or (ii) additional restrictions of "root"
> >>> >> to top-level nodes. (The Y34-04 referes to ncx:root which is not known
> >>> >> to everybody.)
> >>> >>
> >>> >
> >>> >
> >>> > There are corner cases like YANG Patch edit value that need to be
> >>> > anyxml.
> >>> >
> >>> >> Would adoption of Y34-02 with the additional text (the three list
> >>> >> items) of Y34-04 be a workable solution?
> >>> >>
> >>>
> >>>
> >>> The discussion in the last VI meeting seemed to favor this solution
> >>> but there is still this issue of JSON -> XML -> JSON round-trip
> >>> conversion of anydata (unstructured data).
> >>>
> >>> IMO the loss of JSON typing through the XML conversion
> >>> is not an issue because the only schema that matters is
> >>> the YANG anydata.  E.g.,  booleans and numbers are
> >>> just strings. null is not supported.  All simple nodes are
> >>> strings.  There are no keys so there are no real arrays.
> >>> The server may return multiple containers that could
> >>> have been encoded as an array.
> >>>
> >>
> >> Yes, the JSON I-D must be updated to define how anydata is encoded.
> >>
> >> In general, I believe a JSON receiver must be able to do conversions
> >> if needed, that is, if the JSON type does not match the type of the
> >> YANG data model, the receiver must convert as needed instead of
> >> throwing an error. I believe the YANG type is authoritative, not the
> >> type used in the encoding. Lada may not like this but since the two
> >
> > Well, I fully agree that YANG types should be authoritative but,
> > strangely enough, it leads me to a completely different conclusion: If a
> > leaf is defined as uint8, and both parties are supposed to know that,
> > why should the sender want to encode it as string?
> >
> 
> Because we are talking about anyxml, not uint8.
> The entire point of anyxml is that is carries absolultely
> no YANG schema information whatsoever.
> The peer parsing the node has no way to associate
> uint8 with any sub-node of the anyxml blob.

In the generic case this is true.

But for example in YANG PATCH, the target node is known from the
context, so the anydata blob can/will be parsed according to the
schema.


/martin