Subject: [netmod] bit statement bug

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Aug 2009 10:20:33 +0200 (CEST)

Hi,

A bit name is currently restricted to be an identifier.  I think this
is a bug - at some point in time both enums and bits were supposed to
be identifiers, but we relaxed this.  The text reflects this for
enums, but not for bits.  For example, the usage example in 9.7.5 has
this:

             bit 10-Mb-only {
                 position 2;
             }

but this is not legal according to the current text and grammar.

I suggest this change to 9.7.4:

OLD

   The "bit" statement, which is a substatement to the "type" statement,
   MUST be present if the type is "bits".  It is repeatedly used to
   specify each assigned named bit of a bits type.  It takes as an
   argument a string which is the assigned name of the bit.  It is
   followed by a block of substatements which holds detailed bit
   information.  A bit name follows the same syntax rules as an
   identifier (see Section 6.2).

NEW

   The "bit" statement, which is a substatement to the "type" statement,
   MUST be present if the type is "bits".  It is repeatedly used to
   specify each assigned named bit of a bits type.  It takes as an
   argument a string which is the assigned name of the bit.  The
   string MUST NOT be empty and MUST NOT contain any
   whitespace characters.  The use of control codes SHOULD be avoided.

   The statement is optionally followed by a block of substatements
   which holds detailed bit information.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Aug 2009 10:45:44 +0200

>    which holds detailed bit information.

I agree that the text for enums and bits should be identical.

/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: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Aug 2009 11:05:12 +0200 (CEST)

> I agree that the text for enums and bits should be identical.

Clever ;)

Ok, so the enum text has this:

   The string MUST NOT be empty and MUST NOT have any leading or
   trailing whitespace characters.

And my proposed bit text has this:

   The string MUST NOT be empty and MUST NOT contain any whitespace
   characters.

The reason for the latter is that bits are encoded as space separated
list of the string values:

       <mybits>disable-nagle 10-Mb-only</mybits>

So we can't allow whitespace in the name.

So then the question becomes - should we limit enum names to not
contain whitespace just so that enums and bits are treated the same?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Aug 2009 12:09:19 +0200

> contain whitespace just so that enums and bits are treated the same?

I see, there is a technical reason for the difference. I guess for
most data model writers it is simpler if there is only one set of
rules and for both enums and bits but hardcore no CLR people will
surely argue that we have no technical reason to disallow whitespace
inside an enum label. I understand both sides but I guess I tend
towards making the rules for enums and bits identical. If we make them
different, we should perhaps shortly explain why they are different so
we easily recall the reason.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Aug 2009 03:30:23 -0700

> contain whitespace just so that enums and bits are treated the same?

This is not a bug, it is a feature. ;-)
We went over this entire issue a year ago (or more).
We decided that bit names needed to be valid identifiers.
I do not see any compelling reason to change that now.
The number of specialized CLRs in YANG is already high enough.
This would be yet another variant of a special rule.

> /martin

Andy

---

From: "tom.petch" <[email-masked]>
Date: Tue, 25 Aug 2009 10:05:08 +0200

----- Original Message ----- 
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 24, 2009 10:20 AM
Subject: [netmod] bit statement bug

>    which holds detailed bit information.

Martin

Yes, it works, but ... terminology.  A minor point here but typical of 
what can be a bigger one elsewhere.

Reading this suggests to me we have a concept of 'assigned name' which 
would then be different from a name which is of course different from
an identifier:-)  I am (again) left unsure if I know what it means - really.
And you have omitted the next sentence which then refers not to 'assigned
name' but to 'bit names':-(

If 'assigned name' is not something special, then I would recast it along 
the lines of

'Each bit statement assigns (specifies) a name to (for) a bit.  It takes as an
 argument a string which is the name of the bit.'

or being analytical, get rid of adverbs whenever possible, use verbs for 
the action and reduce the number of terms to the number of concepts.

At a tangent, I suggest in the ABNF comment for WSP
/white space/whitespace/
I know I don't know what whitespace is in YANG but always struggle
to find the formal definition when I search on 'whitespace'.

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 25 Aug 2009 12:00:11 +0200 (CEST)

Hi,

"tom.petch" <[email-masked]> wrote:
> Yes, it works,

So far, I am not introducing this change.  Andy was against, Juergen
was maybe for it.  But your comments apply to the original text as
well.

> but ... terminology.  A minor point here but typical of 
> an identifier:-)

Section 9.7 says:

   The bits built-in type represents a bit set.  That is, a bits value
   is a set of flags identified by small integer position numbers
   starting at 0.  Each bit number has an assigned name.

So this is where the "assigned name" is defined.  Now, I guess we
could s/assigned name/name/ but would that really solve a real
problem?   (we'd have to do it form enums as well).

>  I am (again) left unsure if I know what it means - really.

Fixed.  bit names is now assigned name.

> At a tangent, I suggest in the ABNF comment for WSP

Fixed.

/martin

---

From: Per Hedeland <[email-masked]>
Date: Tue, 25 Aug 2009 13:03:01 +0200

On 2009-08-25 12:00, Martin Bjorklund wrote:
> was maybe for it.

I don't think it is a big problem, but restricting the bit names to be
identifiers seems like a completely arbitrary and pointless rule, which
is something I generally find confusing. So here's a vote *for* the
change (bugfix), and including a note motivating the difference from
enum names as suggested by Juergen would be a good idea I think.
Restricting also enum names to be identifiers would be worse than the
current situation IMO.

--Per Hedeland

---

From: "tom.petch" <[email-masked]>
Date: Tue, 25 Aug 2009 18:35:20 +0200

Martin

OK

Tom Petch