Subject: [netmod] more fun with YIN

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

Hi,

Here's another design hole in YIN:

  extension fubar {
    argument xmlns {
      yin-argument false;
    }
  }

  leaf X {
    type string;
    X:fubar "http://acme.com";
  }

  <yin:leaf name="X">
    <yin:type name="string" />
    <X:fubar xmlns="http://acme.com" />
  </yin:leaf>

The 'xmlns' name is special for attributes, but not elements.

A YANG user might assume that YANG deals with
this problem, like it deals with entity replacement
and other XML details.  That YANG user would be wrong.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 15 Dec 2009 19:00:04 -0500

>Here's another design hole in YIN:

Not just YIN.  This is another design hole in all of YANG.
http://www.w3.org/TR/xml/ clearly says:

   Names beginning with the string "xml", or with any string which
   would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for
   standardization in this or future versions of this specification.

Your comment applies here also:

I guess our only choice is to fix this in the YANG spec
by mirroring the TR's language.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Dec 2009 05:03:03 -0800

> by mirroring the TR's language.

This applies to all elements and attributes?

Talk about CLRs!
I guess the W3C can't avoid them either.

So this would affect all YANG keywords,
all extension names, and all extension argument names, right?
It does not affect any other YANG argument string values, right?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Dec 2009 05:08:50 -0800

> It does not affect any other YANG argument string values, right?

oops, forgot rpc-stmt and notification-stmt names.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 Dec 2009 14:09:14 +0100 (CET)

> It does not affect any other YANG argument string values, right?

Right.  I think the simplest fix is to make this rule part of a
'identifier'.  It is actually a bit too broad, since an 'identifier'
for a choice or module, for example, could start with "xml" without
any problem.  The alternative is to introduce another type of
identifier which we use for selected keywords.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Dec 2009 14:22:02 +0100

> identifier which we use for selected keywords.

Actually, the XML Namespaces REC says that names like foo:xmlns are not
reserved, but it is definitely better to state the rule as you suggest.

Lada

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

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Dec 2009 05:38:38 -0800

> reserved, but it is definitely better to state the rule as you suggest.

When does a container, leaf, leaf-list, or leaf name show up
in an XML element or attribute name?

  container xml;

  <yin:container name="xml" />

I think it only applies to 'container' and 'name' in this example.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Dec 2009 05:41:33 -0800

> I think it only applies to 'container' and 'name' in this example.

oops, never mind.
NETCONF databases have identifiers encoded as element names.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 Dec 2009 14:42:48 +0100 (CET)

> in an XML element or attribute name?

  leaf foo { ... }

In NETCONF:

  <foo>42</foo>

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Dec 2009 14:46:18 +0100

> in an XML element or attribute name?

In NETCONF PDUs. Instead of banning names starting with [xX][mM][lL],
YANG XML encoding could require explicit prefixes for all node names.
I don't think it is a good idea though.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Dec 2009 15:55:47 +0100

> identifier which we use for selected keywords.

If we do constrain identifiers to match XML constraints on element /
attribute names, we should do this for all identifiers so we (a) less
likely get it wrong and (b) do not have to continuously explain why
identifiers are different and (c) we are future proof just in case
something not originally intended to be shipped in XML elements /
attributes suddenly needs to be shipped as XML elements / attributes.

/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: Wed, 16 Dec 2009 08:09:12 -0800

> attributes suddenly needs to be shipped as XML elements / attributes.

I don't think we have any other options.
If 'xml' is reserved then the 'xmlns' problem is solved.
If we ignore the XML rule even though we know about it,
then the IESG is going to flag it with a DISCUSS.
They have enough work to do already on this spec,
so we have to fix this now.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Dec 2009 17:51:08 +0100

> then the IESG is going to flag it with a DISCUSS.

Your trust in the IESG is unbelievable. Please point me to other RFCs
that use XML where I can find a template of the text to be added. I
believe we management people tend to be more precise on such issues
then most are people are...

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Dec 2009 09:17:45 -0800

> then most are people are...

OK, so they just use XML by reference.
We should do what we think will help implementors
do the right thing.  Putting the rule in the identifier rule
seems like a good idea.  The semantics are in comments anyway.
Martin can just add a reminder in the comments, instead of adding
cut-and-paste normative text.

Andy