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

[Juergen Schoenwaelder <[e-mail]>]

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
type systems do not align 1:1, I think giving the YANG type system
authority is the way to go. And the principle "the receiver converts
as needed" instead of throwing an error follows the Postel principle.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>