Subject: [netmod] Y35: allow empty in union

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Jun 2015 12:16:55 +0200 (CEST)

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.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 28 Jun 2015 16:16:17 +0200

>    A leaf that is part of the key can be of any built-in or derived

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

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

---

From: Andy Bierman <[email-masked]>
Date: Sun, 28 Jun 2015 07:42:27 -0700

> I am OK with removing a constraint preventing a specific case of such
I think the list can have 1 instance.

/js

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 28 Jun 2015 17:11:28 +0200 (CEST)

> I think the list can have 1 instance.

Yes.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 28 Jun 2015 18:21:10 +0200

> > I think the list can have 1 instance.

OK. I guess RFC 6020 section 9.11.2. confused me. Is the lexical
representation not simply an empty string? I mean, it seems that

  <foo>
    <id></id>
  </foo>

would be as valid as

  <foo><id/></foo>

or am I confused? And in JSON it would be this?

   "foo": [
    {
      "id": [null]
    }
    ]

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 28 Jun 2015 20:55:39 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> 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

Correct.

> or am I confused? And in JSON it would be this?

I think this is correct.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 28 Jun 2015 12:10:35 -0700

> > or am I confused? And in JSON it would be this?
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).

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 28 Jun 2015 21:14:42 +0200 (CEST)

> 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

---

From: Andy Bierman <[email-masked]>
Date: Sun, 28 Jun 2015 12:18:01 -0700

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 29 Jun 2015 15:31:09 +0200

>    A leaf that is part of the key can be of any built-in or derived

I support this.

Lada

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 29 Jun 2015 15:32:29 +0200

Yes.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Mon, 29 Jun 2015 17:40:22 -0400

>I am OK with removing a constraint preventing a specific case of such

Doesn't removing the prohibition require us to accept such nonsense?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Jun 2015 14:51:30 -0700

> Doesn't removing the prohibition require us to accept such nonsense?

No - using 'empty' as a key allows 1 instance, same as a container.
It may be pointless bug not harmful.

We currently allow things in YANG 1.1 such as "mandatory true"
on an enumeration leaf, yet if-feature is allowed on enum-stmt so
it could be the server will not actually accept any of the values,
yet the leaf is still mandatory.  (At least for bits the
server will accept an empty bit set, but not enumeration).

Thanks,
Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Jun 2015 07:52:03 +0200

> Doesn't removing the prohibition require us to accept such nonsense?

I am not afraid of nonsense in data models since nonsense will not be
implemented. I would leave it to compiler writers to warn about
nonsense constructions a compiler can detect without requiring a
statement in the language definition trying to prohibit nonsense.
There are many ways to define degenerated lists in YANG; ruling out
one of them does not help that much and it creates inconsistencies -
why is one way to define a degenerated list forbidden but the others
are legal?

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 30 Jun 2015 09:51:50 -0400

>It may be pointless bug not harmful.

Requiring implementation of pointless features is, well, pointless.
It's an expense that can be safely removed.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 30 Jun 2015 10:00:11 -0400

>why is one way to define a degenerated list forbidden but the others

This really isn't the way standards work, right?  "gcc" can warn when
I do something like "int foo(){ return 0; return 1;}" but it can't
decide that it's invalid or refuse to generate a .o file for it.
I can choose to tighten gcc's restrictions with -W flags, but when
code compiles under gcc and doesn't under clang, when one or the
other isn't implementing the C standard.

Past that, allowing pointless constructs like this allows users
to make mistakes that might not be warned by their tool chain,
and the earlier an error is caught, the lower it's cost.

Worse, allowing pointless constructs like this means that the
probability of some nitwit using it quickly approaches 1, at
which point tool chains that barf on it will need to start
supporting it.

I'm not asking us to make pointless constructs like "leaf foo {must foo==0;}"
but empty keys it truly pointless.  Making it illegal is a benefit
to the enitre YANG world and not doing so it a pointless expense.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 30 Jun 2015 16:14:41 +0200

> On 30 Jun 2015, at 15:51, Phil Shafer <[email-masked]> wrote:
> 
> Andy Bierman writes:

Requiring implementation of pointless CLRs is, well, pointless.
It’s an expense that can be safely removed.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Jun 2015 16:37:05 +0200

> other isn't implementing the C standard.

I don't get it. I do not think the C standard says the example above
is invalid C. It is perhaps pointless C or likely a coding error but
as long as the semantics are clear, things are well defined.

> which point tool chains that barf on it will need to start

You can achieve the same pointless construct in many other ways.
Trying to enumerate all of them is tricky and it is very easy to make
mistakes.

> to the enitre YANG world and not doing so it a pointless expense.

I guess it is subjective where to draw the line. Disallowing empty in
a key but at the same time allowing the example Martin presented shows
that the line is really somewhat arbitrary.

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 30 Jun 2015 11:25:52 -0400

>as long as the semantics are clear, things are well defined.

Your comment was "nonsense will not be implemented"; my point was
that tool chains will still need to implement it regardless of
whether we think it will see use.  If it's legal nonsense, a tool
chain that doesn't support it is broken.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Jun 2015 08:58:45 -0700

Hi,

The server already has to support a list if the key
is an enum with 1 value or a string with "length 0".

The only advantage is that it let's a union with an empty in it
be used as a key.

Andy