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.
Same problem with this:
leaf broken2 {
type union {
type string;
type int32;
}
}
If set via XML <broken2>42</broken2> will be a string, but in JSON,
"broken2": 42 is an int32.
/martin
> 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
