Hi,
Notice we already have this XML vs. JSON
encoding problem in RESTCONF for numbers
leaf broken2 {
type union {
type string;
type int32;
}
}
In XML, <broken2>42<broken2> will always resolve to a string
in the example above. In JSON it will be string or int32.
In order for a union to work correctly in all encodings
it must be specified so the types are ordered from most specific
to most generic. This is not any rule in YANG, but
maybe it should be a rule (YANG guidelines draft?)
Andy
On Sun, Jun 28, 2015 at 12:10 PM, Andy Bierman <[email protected]> wrote:
>
>
> On Sun, Jun 28, 2015 at 11:55 AM, Martin Bjorklund <[email protected]> wrote:
>
>> Juergen Schoenwaelder <[email protected]> wrote:
>> > On Sun, Jun 28, 2015 at 05:11:28PM +0200, Martin Bjorklund wrote:
>> > > Andy Bierman <[email protected]> wrote:
>> > > > On Sun, Jun 28, 2015 at 7:16 AM, Juergen Schoenwaelder <
>> > > > [email protected]> wrote:
>> > > >
>> > > > > On Wed, Jun 24, 2015 at 12:16:55PM +0200, Martin Bjorklund wrote:
>> > > > > > Hi,
>> > > > > >
>> > > > > > Currently we have an inconsistency in
>> > > > > > draft-ietf-netmod-rfc6020bis-05. With Y35, we allow type empty
>> in
>> > > > > > unions. But section 7.8.2 says:
>> > > > > >
>> > > > > > A leaf that is part of the key can be of any built-in or
>> derived
>> > > > > > type, except it MUST NOT be the built-in type "empty".
>> > > > > >
>> > > > > > This means that this is legal:
>> > > > > >
>> > > > > > typedef my-empty {
>> > > > > > type union {
>> > > > > > type empty;
>> > > > > > }
>> > > > > > }
>> > > > > >
>> > > > > > list foo {
>> > > > > > key id;
>> > > > > > leaf id {
>> > > > > > type my-empty;
>> > > > > > }
>> > > > > > ...
>> > > > > > }
>> > > > > >
>> > > > > > I suggest we allow type empty also in keys:
>> > > > > >
>> > > > > > NEW:
>> > > > > >
>> > > > > > A leaf that is part of the key can be of any built-in or
>> derived
>> > > > > > type.
>> > > > >
>> > > > > And my understanding is that the list foo defined above will never
>> > > > > have an instance, correct? I assume decent compilers will
>> continue to
>> > > > > create warnings when they can decide that a list will never have
>> any
>> > > > > instances. (And yes, there are other ways to construct such
>> lists, so
>> > > > > I am OK with removing a constraint preventing a specific case of
>> such
>> > > > > useless lists.)
>> > > > >
>> > > > >
>> > > > I think the list can have 1 instance.
>> > >
>> > > Yes.
>> > >
>> >
>> > OK. I guess RFC 6020 section 9.11.2. confused me. Is the lexical
>> > representation not simply an empty string?
>>
>> No, since the empty string in JSON is "".
>>
>> A leaf of type empty doesn't have a value, thus there is no lexical
>> represention.
>>
>> > I mean, it seems that
>> >
>> > <foo>
>> > <id></id>
>> > </foo>
>> >
>> > would be as valid as
>> >
>> > <foo><id/></foo>
>>
>> Correct.
>>
>> > or am I confused? And in JSON it would be this?
>> >
>> > "foo": [
>> > {
>> > "id": [null]
>> > }
>> > ]
>>
>> I think this is correct.
>>
>>
> So you are saying that XML and JSON could encode the
> following leaf differently:
>
> leaf broken {
> type union {
> type string;
> type empty;
> }
> }
>
> If set with XML then an empty string or empty type look the same:
>
> <broken></broken> OR <broken />
>
> Both will be treated as a string if encoded in XML.
> But in JSON, the encoding will be [null] or "",
> and the server will save the type as either string or empty.
>
> The server remembers the type that wins when a union is
> parsed, so the leaf will be rendered correctly. This is important
> even for XML (e.g., identityref, instance-identifier, xpath1.0).
>
>
>> /martin
>>
>
>
> Andy
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
