Subject: [netmod] yin-element is useless

From: Andy Bierman <[email-masked]>
Date: Sun, 13 Dec 2009 11:29:52 -0800

Hi,

Now that I am bothering to implement YIN,
I can't help notice that it is a CLR factory.
I cannot find any meaningful rationale for
picking yin-element == true or false.
The decision to encode as an attribute seems
completely arbitrary and pointless.
Memorizing the table of hard-wired values
in the draft seems like a waste of time.

I also find the arbitrary names picked for
the argument strings to be pointless and
a just more CLRs.  Every one of them
could be called <arg> and it would
make YIN easier to understand.  These
arbitrary argument names disappear in YANG.

YIN should always use elements and not attributes.
That would simplify encoding, reduce YANG CLRs,
reduce implementation complexity, and simplify the
extension-stmt (no need for yin-element sub-statement).

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sun, 13 Dec 2009 21:58:06 -0500

>completely arbitrary and pointless.

It is based on expected use and content.

>in the draft seems like a waste of time.

You are not required to comment them to memory.  Any
tests or quizes will be open book.

>arbitrary argument names disappear in YANG.

The name is meant to be meaninful and to
match the use.

>extension-stmt (no need for yin-element sub-statement).

-1.  Leave it as is.  Ship this baby.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 13 Dec 2009 19:43:12 -0800

> tests or quizes will be open book.

Yes, but only because I never intend
to write modules in YIN.  Since the WG
thinks it is important to type modules in XML,
they intend for YANG authors to memorize
these pointless and arbitrary choices.

> The name is meant to be meaninful and to

it is neither

the use is a plain old argument string
with no name in YANG.  Adding arbitrary names to
memorize in YIN is poor engineering.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sun, 13 Dec 2009 22:59:28 -0500

>these pointless and arbitrary choices.

I won't speak for the WG, but there should be no assumption that
"it is important to type modules in XML".  The comments in the arch
draft talk about how this is used when XML parsers are the only
choice.  The plan is that humans (including YANG authors) will use
the YANG format but can use a distinct/offline YANG parser to make
YIN that can be used in places where XML parsers are more easily
available.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Dec 2009 04:01:17 -0800

> YIN that can be used in places where XML parsers are more easily

Well, IMO YIN is not important enough to worry about.
Certainly not worth the trouble of implementing it.
Nobody is going to use it, so the fact that it
is poorly engineered is not that important.  What a win!

If it's just for machine translation, then
the arbitrary choices are especially useless.
Machines like boring, predictable, simple patterns,
not ad-hoc, hard-wired tables that require the
extension-stmts from all the imported modules
to be parsed.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Dec 2009 15:10:24 +0100

> in the draft seems like a waste of time.

I don't agree, it is very consistent. yin-element is used only in those
cases where the text might be inappropriately modified by the standard
XML attribute normalization.

I am using YIN as the primary source format for writing YANG modules and
I like the current status. Of course, we could ignite another flame war
regarding elements versus attributes but IMO it is irrelevant.

Lada

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

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Dec 2009 15:26:30 +0100

> these pointless and arbitrary choices.

I guess writing YIN (or any XML, for that matter) makes sense only with
a schema-aware editor. I am using emacs with nxml-mode and don't need to
memorize anything. And it is considerably faster than writing YANG
compact syntax.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Dec 2009 15:42:05 +0100 (CET)

> regarding elements versus attributes but IMO it is irrelevant.

I also think it is good enough as it is.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 14 Dec 2009 10:06:24 -0500

>I also think it is good enough as it is.

Amen.  Ship it.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Dec 2009 20:39:06 +0100

> completely arbitrary and pointless.

[...]
 
> a just more CLRs.

So is there a guiding principle behind Table 1? Any advise how
extension writers should use the yin-element statement? Note that we
would not even need yin-element if there would be a simple translation
rule (and note that the yin-element statement hard codes the rule for
choosing the attribute name, which means what is in table 1 could have
not been created with YANG extension statements - am I correct?).

/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, 14 Dec 2009 20:48:45 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> extension writers should use the yin-element statement?

Lada provided a guideline:

  yin-element is used only in those cases where the text might be
  inappropriately modified by the standard XML attribute
  normalization.

> Note that we

Do you mean that we could not define the yin-element statement itself
with an extension?  Or do you mean that we could not have defined the
rest of the statements as extensions?

The attribute name is the name of the argument:

  extension annotate {
    argument target;
    ...
  }

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Dec 2009 12:13:09 -0800

> not been created with YANG extension statements - am I correct?).

IMO, this is cleaner:

    keyword [arg] stmt-end

    <keyword>
       <arg>foo</arg>
    </keyword>

It would be nice to have a simple fool-proof algorithm
that does not require a tool to parse and understand
all the imported extension-stmts.

YANG fragment:

  module X {

   extension foo {
      argument bar {
        yin-element true;
      }
   }

   extension bar;

   container A {
      x:foo fred {
         x:bar;
      }
   }

current YIN encoding:

   <yin:container name="A">
     <x:foo>
       <x:bar>fred</x:bar>
       <x:bar />
     </x:foo>
   </yin:container>

proposed YIN encoding:

   <yin:container>
     <yin:arg>A</yin:arg>
     <x:foo>
       <yin:arg>fred</yin:arg>
       <x:bar />
     </x:foo>
   </yin:container>

It is not possible to guess 100% of the corner-cases
using the current extension-stmt.  I prefer:

   extension foo {
      argument true;
   }

   extension bar {
     argument false;
  }

The mapping rules are simple:
  1) YANG keywords map to elements in YIN namespace
  2) all arguments map to <arg> keyword in YIN namespace
  3) all extension keywords map to elements in the module namespace

This is bullet-proof, simple, requires no knowledge
of any YANG extension-stmts, and does not lead
to the 'double <x:bar> element' problem that exists in
the current solution.  XML encoding and XML namespace rules
are different for attributes than elements, and that complexity
is also avoided.

But if the people that actually want to use YIN like it
so much just the way it is, then I don't think it
should be changed.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Dec 2009 21:18:55 +0100

>   inappropriately modified by the standard XML attribute

What is the definition of "inappropriately modified"? Even text in
elements gets modified.
 
> The attribute name is the name of the argument:

Yes, but for the contact statement, the yin attribute is called 'info'
(OK, there is a proposal to change this). Since table lists different
names for the attributes, it seems these statements could never have
been defined using extension statements. If it is important for some
reason (yet to be posted) to choose name/value/info/..., then perhaps
this same reason might apply for extension statements as well.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Dec 2009 23:16:19 +0100

>     </keyword>

I becomes less clean if there are any substatements:

    <keyword>
      <arg>foo</arg>
      <subkw>
        <arg>bar</arg>
      </subkw>
      ...
    </keyword>

As an attribute, the argument is clearly distinguished from the
substatements.

However, it seems attribute normalization may still be a problem for
some statements with yin-element=false. For example, in

<default value="foo    bar"/>

the attribute value will get normalized to "foo bar" (single space),
which may cause interoperability problems.

So I guess Andy's proposal is worth considering. There are pros and cons
in either case.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 15 Dec 2009 00:08:32 +0100 (CET)

> which may cause interoperability problems.

In the absense of a DTD, won't the attribute be treated as CDATA?  If
so, you will not get a single space, but tab etc will still be
converted to space.

> So I guess Andy's proposal is worth considering. There are pros and cons

Or we go through the list and make sure that all statements where
attribute normalization can be a problem use elements.  'default' is
one example.  There are a few more.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Dec 2009 15:54:12 -0800

> I becomes less clean if there are any substatements:

This always translates to

  keyword foo {
     subkw bar;
  }

> As an attribute, the argument is clearly distinguished from the

As long as the string 'arg' (or whatever) is never
used as a YANG keyword, then there is no ambiguity.
If there is a YANG argument, it will be the first child node
of the keyword element.

> So I guess Andy's proposal is worth considering. There are pros and cons

I was told a long time ago by you guys
that attributes were bad, and that's why we never
use them in the XML encoding of YANG.

Now we are told XML attributes are good, and
must be supported for YIN arguments.

I think Juegen is right -- some clarification
should be added why YANG does not support attributes
yet YIN needs them.  Even stuff like patterns,
ranges and XPath expressions can have whitespace issues.

Currently, the extension argument name can collide
with another extension name, ala my example:

  x:foo fred {
     x:bar;
  }

  <x:foo>
   <x:bar>fred</x:bar>
   <x:bar />
  </x:foo>

This seems like a problem to me, especially if
the order of the <x:bar> elements is not preserved.

  <x:foo>
   <yin:arg>fred</yin:argr>
   <x:bar />
  </x:foo>

This is never ambiguous, even when mis-ordered.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Dec 2009 09:51:04 +0100

> so, you will not get a single space, but tab etc will still be

Well, XML 1.1 spec says in sec. 3.3.3:

"If the attribute type is not CDATA, then the XML processor MUST further
process the normalized attribute value by discarding any leading and
trailing space (#x20) characters, and by replacing sequences of space
(#x20) characters by a single space (#x20) character.
...
All attributes for which no declaration has been read SHOULD be treated
by a non-validating processor as if declared CDATA."

I am wondering what this means for a validating parser which doesn't use
DTD. I checked it with xmllint and it doesn't collapse multiple spaces
even if the attribute is declared as "string" or "token" in RELAX NG.

But in any case, tabs and newlines are always changed to spaces.

> one example.  There are a few more.

Yes, it seems necessary for 'default', 'enum' 'must', 'path', 'pattern'
and 'when'.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 15 Dec 2009 10:40:45 +0100 (CET)

> Yes, it seems necessary for 'default', 'enum' 'must', 'path', 'pattern'

I prefer to fix the current design, i.e. make the argument for these
keywords elements.

Provided we fix these problems, I think it is a matter of taste which
design is better.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Dec 2009 11:16:47 +0100

> This always translates to

Sure, but any more complex hierarchy will become completely unreadable,
you have to care about subelement order etc. I don't agree that YIN may
only be useful as an internal format for machine processing.

...

> use them in the XML encoding of YANG.

Attributes are not bad, they just have some limitations that have to be
taken into account.

> yet YIN needs them.  Even stuff like patterns,

This is pretty clear: for containers it's out of question and making
leafs into attributes would prevent adding attributes to them, e.g. to
specify edit-config operation.

For YIN, there are no such issues, except value normalization.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Dec 2009 11:17:52 +0100

> I prefer to fix the current design, i.e. make the argument for these

+1. Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Dec 2009 08:21:08 -0800

> only be useful as an internal format for machine processing.

I disagree.
IMO the predictable algorithm makes
it easier to read, and easier to
remember what arbitrary name was used
for the un-named argument string.

> specify edit-config operation.

The keyword is always encoded as an element, so
this is never a problem.  The ad-hoc, random
assignment of name and attr vs. element only
applies to the optional argument string.
I'm surprised the WG did not add alternate encodings
for the keyword.  It is static and predictable
for some reason.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Dec 2009 08:51:15 -0800

>> I prefer to fix the current design, i.e. make the argument for these

Maybe you can start with the functional requirements.

 - We have a conceptual field in a YIN-stmt.
 - It is optional.
 - There can be zero or one instance of this field.
 - There is no need for an assignable name for this field in YANG

I do not understand why this field even needs an assignable name in YIN.

 - If there could be multiple arguments, then this would make sense.
 - If the name had any semantics at all associated with it,
   but it doesn't.
 - If there were not significant problems with assignable name collisions,
   like there are between keyword and argument name.
 - If there were some benefit from using XML attribute encoding
   over XML element encoding like the rest of YANG.  (BTW, there
   are corner-cases introduced by encoding 'string' in an
   attribute in YIN, but an element in YANG.  These are never
   explained in the draft.)

I hope the WG does not solve these problems
with more lame CLRs.  I prefer algorithms that actually
work, instead of pushing the problem on the user,
with lots of CLRs that cover up the design holes.

Andy