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
