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

Andy Bierman <andy@yumaworks.com> writes:

> On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman <andy@yumaworks.com> wrote:
>> On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder
>> <j.schoenwaelder@jacobs-university.de> wrote:
>>> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote:
>>>> Hi,
>>>>
>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> 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.

So it seems JSON encoding will change (compared to
draft-ietf-netmod-yang-json-02, sec. 5.5) only so that null will be
allowed only in a single-element array ("[null]") and array containing
both scalar values and objects/arrays won't be allowed.

Is it correct?

Lada

>
>
>>
>> yes
>>
>>
>>> /js
>>>
>>
>> Andy
>>
>
> Andy
>
>
>>> --
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>>> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C