Re: [core] Comments on draft-ietf-core-yang-cbor-00

[Ladislav Lhotka <[e-mail]>]

> On 24 May 2016, at 16:29, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> On Tue, May 24, 2016 at 04:25:13PM +0200, Ladislav Lhotka wrote:
>> 
>>> On 24 May 2016, at 14:36, Juergen Schoenwaelder <[e-mail]> wrote:
>>> 
>>> On Mon, May 23, 2016 at 01:22:59PM +0200, Ladislav Lhotka wrote:
>>> 
>>>>> YANG's native serialization of values are untyped strings.
>>>> 
>>>> To my knowledge, this hasn't been stated as a design feature for YANG,
>>>> it's just a side effect of XML being the only serialization that was
>>>> considered when YANG was being designed.
>>> 
>>> We use string representations of values in other contexts, e.g., when
>>> writing pattern restrictions or when evaluating xpath expressions. We
>> 
>> Actually, pattern restrictions are only possible for the "string" type.
>> 
>> And XPath is not limited to strings, we can write, e.g.,
>> 
>>    must ". mod 2 = 0";
> 
> But the expression is at least conceptually evaluated on a string
> representation of what is being interpreted as a number.

Hmm, I would say it's just the other way around: for example, XPath expression "foo = 0" evaluates to true even if "foo" happens to have YANG "string" type and value of "00".

> 
>>> also do define canonical string formats for our types.
>>> 
>>> Note, this does not mean an implementation has store internally all
>>> values as strings but when it matters, the string representation of
>>> values defines the behavior. Except for unions in JSON...
>>> 
>>> My take has been that non-XML encodings may take advantage of being
>>> able to present data mode 'efficiently' (CBOR) or to make it easier
>>> for applications / libraries (JSON). For me, encodings that change how
>>> we interpret types at the YANG level are somewhat surprising.
>> 
>> The problem is that XML, JSON and CBOR are not just different encodings (as in Unicode) but rather different ways for representing structured data, and each has different priorities and semantics. I don't think that "gleichgeschaltetes" JSON or CBOR, where everything is a string, is an attractive option.
> 
> And I did not suggest that. All I said is that encodings should not
> change how the YANG type system works. I continue to find that broken.

I don't think CBOR or JSON really change how YANG type system works. They just provide some extra information that (unfortunately) isn't available in XML serialization. Rather than blaming non-XML serializations, we should think about a generic way for signalling the actual member type that can be used whenever the chosen serialization falls short. If we have, e.g.

leaf foo {
  type union {
    type string;
    type uint8;
  }
}

then it should IMO be possible to pass a number, no matter what the encoding is. So nothing extra needs to be done in JSON and CBOR, but in XML encoding the data could be sent as

<foo member-type="2">42</foo>

Lada  

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

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