Subject: [netmod] Filename recommendation (Was: <CODE BEGINS> convention)

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Dec 2009 20:56:40 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> On Fri, Dec 04, 2009 at 09:26:38PM +0100, Andy Bierman wrote:
> 
> > >> yep -- I begged the WG (early on) to reserve 1 printable
> > >> character from identifiers, but people insisted they need
> > >> the freedom to use every legal XML identifier value.
> > > 
> > > My keyboard still has characters left that are not allowed in a legal
> > > YANG identifier - so I do not see this as a hard engineering challenge.
> > 
> > Really?
> > So which characters are available that are
> > present on every keyboard, and are not special
> > characters in any operating system filespec?
> 
> I assume every keyboard has a '+' for example. And I was not talking
> about "any operating system filespec". I was talking about (a) picking
> a character that is not a legal module name character and (b) avoiding
> the '.' since it is used by major OSes as a separator for the file
> type suffix.

Which major OS will have a problem with this?  The Wikipedia article
on Filenames (http://en.wikipedia.org/wiki/Filenames)says this on '.':

  allowed but the last occurrence will be interpreted to be the
  extension separator in VMS, MS-DOS and Windows. In other OSes,
  usually considered as part of the filename, and more than one full
  stop may be allowed.

Using the filename <module>[.<revision>].yang is just a recommendation
anyway.  Modules need not be stored in files.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 07 Dec 2009 11:59:20 -0800

> anyway.  Modules need not be stored in files.

If we are going to have a recommendation at all,
then we should have one that actually works.
It should be obvious that the separator char
between the module name and the revision-date
cannot be a valid module name character.

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Dec 2009 21:10:36 +0100 (CET)

> cannot be a valid module name character.

When you say that it doesn't work, do you mean because with the
current scheme, you cannot have revision '2009-04-01' of the module
'foo' in the same directory as you have the module with the name
'foo.2009-04-01'?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 07 Dec 2009 12:17:21 -0800

> 'foo' in the same directory as you have the module with the name

yes.

I think @ is a legal file name char, but it is not
a legal module name char, so a module named foo.2009-01-01
can never collide with module foo@2009-01-01.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Dec 2009 21:31:24 +0100

> 'foo' in the same directory as you have the module with the name

For me, this is indeed a concern about corner case that can be easily
avoided by choosing a separator character not allowed in a module
name. This is the technical argument; which character to pick is
probably more a matter of taste.

/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: Tue, 15 Dec 2009 13:27:51 -0800

> probably more a matter of taste.

I do not understand why we didn't catch this obvious bug
in the first place, but it seems to me that the
separator char needs to deterministic for the lowest
interoperability cost.

Using a valid field-char as the field-separator-char
looks like a dumb bug to any high-school student, so
why do we think it represents good standards practice?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 15 Dec 2009 22:37:19 +0100 (CET)

> separator char needs to deterministic for the lowest

Ok.  I agree we should use '@' as separator.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Dec 2009 14:26:19 -0800

> Ok.  I agree we should use '@' as separator.

OK.

Can we agree on some text for the revision issue?
I prefer to have normative text, not just usage guidelines
in this area.

Andy