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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> 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 <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.
>>
>
> 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?

> 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.

If Postel principle is so great, why don't we allow 42.0 as a valid
value of uint8? Why don't we allow "001.002.003.004" as a valid IPv4
address?

Lada

>
> /js
>
> -- 
> 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

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