Re: analysis of YANG vs. RELAX NG

["Rohan Mahy" <[e-mail]>]

Hi,

Comments inline.

On Nov 28, 2007 8:04 AM, Balazs Lengyel <[e-mail]> wrote:

> Hello,
> I am no expert in RelaxNg but here are some thoughts why I like Yang
> better.
>
> I have the feeling once you extend RelaxNg with all the necessary bits,
> half your statements
> will start with <other:xxx>.


We will never know unless we try the exercise. It seems you are suggesting
that we don't even try. However, I see a pretty small number of additional
semantic items you list below:
- an indicator of a default value (if any)
- a flag that indicates whether a subtree is atomic for edit-config
- an indicator that the schema is an rpc method and what its matching
request or response is
- a flag that indicates whether a subtree is configuration or operational
data (read-write or read-only).

Setting that aside for a moment, even if half the statements in a schema are
annotation, the other half can still do something very, very useful.  They
can validate the syntax and structure of the XML received on the wire
automatically in a piece of code (the XML parser) that the implementation
probably already has.

If we decided we wanted to build something like YANG, we would still need a
tool to generate valid XSD or Relax from the YANG definitions to turn on
validation in the XML parser.

There are many aspects that can be somewhat tricky and/or simply time
> consuming, and are
> missing from RelaxNg:


These aspects are not *missing* from Relax NG.  Some of these things are not
in the scope of the Relax NG schema, but can be defined as an additional
layer on top of a specific Relax schema.  We can even write schema which
describes what syntax is allowed for these annotations in a
netconf-semantics namespace.


> - what does a default mean for configuration data


this is semantic.


> - what is considered a compatible or incompatible change


I believe I already covered this. Adding an additional choice (adding a new
rpc method), adding via interleave (adding additional data within a
container), and copying and redefining via restriction or addition (reusing
parts of one container for a new container) are all pretty easy.


> - ordering of items within list, leaf-lists


The schema I described preserves ordering.


> - netconf edit-config semantics


semantic

- differentiating between configuration and operational data


semantic

- differentiating between RPCs, notifications and data containers (in YANG
> you have separate
> statements)


This is easy to do using pure syntax.  As in my example, to add an RPC
method or response, you just "combine with choice" and you insure that the
method isn't used as a notification or a data container.


> - connecting RPC request definitions with RPC reply definitions
>

This is semantic.  I provided an example of how to link these.

- definition of more complex types (IpAddress, MacAddress, ZeroBasedCounter,
> etc.). Nothing
> special but work to do even for RelaxNg


To me this strongly motivates using Relax for the syntax. A language to
define new data types has already been invented and it works very well.

- Netconf specific error messages


If you are talking about error messages sent on the wire, this is a
syntactic issue that Relax can handle out of the box.


> Certainly all these can be done as extensions to RelaxNg as well, but even
> after taking RelaxNg
> as your base, you still have a big work to do. And once your specification
> is complete you need
> to build custom tools to understand the <other:xxx> statements. (For YANG
> we already have
> tools. see http://www.yang-central.org/twiki/bin/view/Main/YangTools)


Are you implying that the act of writing, review, and maintaining a brand
new 150 page specification on YANG is not a lot of work?  I am quite sure
that a motivated group could define just the additional semantics in
substantially fewer pages or text, and that there would be many more
participants in the IETF who could make credible comments on it.



>
> --------------------------------------------------------------------------------------------
>
> For NETCONF readability by operators, untrained in modeling languages, is
> a crucial
> requirement. The question is after how many hours (not days) of training
> can an operator grok a
> YANG model or a RelaxNg model? I feel YANG is easier.


I am hardly a Relax expert. I glanced at the Relax tutorial and the the
Relax book for just under two hours in order to start *writing* schema.  I
have shown relax schema to implementors with no previous experience,
explained how define and ref work on the whiteboard for 5 minutes and then
seen working accessors in under an hour.  The W3C, OASIS, OpenGIS and others
are all using Relax for all of its specifications that use XML going
forward. Perhaps you should spend an hour or two and see what you are
missing.


> One important advantage of YANG is that the number of features in YANG is
> much smaller then in
> RelaxNg.


This is a preposterous statement. There is no need for an operator to learn
features of Relax (or XSD even) that they will never use in order to read
and write schema. I do not understand the finer points of <mixed> content. I
don't need to currently and I can easily skip over and ignore these parts of
the spec.


> If we would count the number of features excluding stuff that is missing
> from RelaxNg,
>   the difference would become even more pronounced.
>
> Generally YANG uses the terminology that network management people are
> familiar with e.g.
> container, augment, configuration data. Learning the RelaxNg terminology
> takes time.


Maybe I have different implementors, but the implementor is more likely to
have some XML experience than to be a "network management person".
Following the principle mentioned in Section 3.1 of
draft-schoenw-sming-lessons-01.txt, the implementor is a "reader" and
simplicity for the reader takes precedence:

   As a consequence, preference should be give to solutions that
   simplify the task of readers.  Reduction of the efforts required by
   writers is of secondary importance and the reduction of the efforts
   required by tool developers is of least important preference.  While
   this perhaps seems obvious, it is at times difficult to take
   according design decisions, especially if the group working on a new
   data modeling language is dominated by tool developers or data model
   writers.



> In the network management world there is a general dislike for so called
> "little rules". Things
> like
> - you can use RelaxNg but don't use attributes
> - you can use RelaxNg but don't use mixed pattern
> - you can use RelaxNg but don't redefine or remove patterns
>
> With RelaxNg we will need a number of such rules. With a problem specific
> solution - YANG -
> the number of such rules is minimal.
>

I disagree. It looks like you have lots of implicit little rules in the YANG
draft. A network management person might have become desensitized to these
rules to the point of not noticing them, but they are there and there are
plenty of them.

thanks,
-rohan


>
> Balazs
>
>
> Rohan Mahy wrote:
> > Hi Martin,
> >
> > More comments inline.
> >
> > On Nov 27, 2007 4:03 AM, Martin Bjorklund <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Hi,
> >
> >     "Rohan Mahy" <[e-mail] <mailto:[e-mail]>>
> wrote:
> >      > I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and
> >      > thought immediately that all of the problems the draft is trying
> to
> >      > address looked very suitable to use RELAX NG as a schema
> language.
> >      > Looking at section F.2 (Why not RELAX NG) I did not see any
> specific
> >      > examples motivating the apparently contradictory statements that
> >     Relax
> >      > is not expressive enough and Relax is too expressive.
> [BALAZS]: Relax can say a number of things we don't need, but can't say a
> number of other
> things we do. If you have thousands of words for ice cream but no words
> for colors then your
> language is too big and too small at the same time.
> >
> >     What we mean with this is that generic XML schema languages such as
> >     RelaxNG and XSD are designed to specify the grammar for (almost) any
> >     XML instance document.  For example they both support mixed content
> >     and XML attributes, neither of which we use in YANG.  You could of
> >     course just state that these constructs MUST NOT be used.
> >
> >
> > Yes, these languages are used to define many schema that do not support
> > mixed content. Defining a set of templates in Relax would make it very
> > clear how the new data should be organized, and is very easy for readers
> > to parse and validate with boatloads of existing tools.  Most netconf
> > implementors will already have an XML parser that will automatically
> > validate against either XSD or Relax schema.
> >
> >
> >     None of these languages support important configuration management
> >     concepts like default values (XSD has a default construct, but it is
> >     not the same); you cannot see if a parameter represents
> configuration
> >     or state data (since it's very domain specific).  In RelaxNG there
> is
> >     not support (by design) for integrity contraints and keys.  None of
> >     the languages have support for specific augmentation (this is
> >     important e.g. for vendors to add vendor-specific stuff to standard
> >     data models).
> >
> >
> > I understand that you want semantic data mixed with your syntax data. I
> > don't think you need to define a new schema language to do this. Relax
> > allows arbitrary annotations in other namespaces, and these annotations
> > can have semantic meaning.  Rather than define a whole new syntax as
> > well, I am much more comfortable defining additional semantics layered
> > on top of an existing schema which validates the syntax.
> >
> >
> >     We also note in the draft that both languages are extensible, and
> with
> >     an extensible language you can add whatever you want.
> >
> >     All this means that the existing tools might not be that simple to
> >     use.  These tools are not aware of any restrictions on the usage
> >     imposed by NETCONF, and they do not understand the NETCONF-specific
> >     extensions.
> >
> >
> > This is a tautological statement. The existing tools will automatically
> > catch large categories of errors automatically (that's as simple as it
> > gets). If you want additional semantic checking, you will define those
> > rules whether you write a whole new language or not.
> >
> >
> >     Another question regarding existing tools is what exactly these
> tools
> >     are supposed to be used for?  Probably not instance document
> (NETCONF
> >     PDU) validation, unless all elements are defined as optional, since
> >     e.g. in an edit-config request you just include the elements you
> want
> >     to modify.
> >
> >      > keyref and instance-identifier are probably better served by
> >     referencing
> >      > an 'id' attribute and using the 'ID' type
> >
> >     The problem with the ID type is that its value is global to a
> >     document.  If the document is the entire configuration datastore,
> all
> >     IDs will have to be unique.  Since you can reference any key (or
> maybe
> >     even any leaf), every key (or leaf) will have to have it's own
> unique
> >     ID.  This won't scale and would be very difficult to maintain.
> >
> >
> > In RAI we had some rather painful experience with referencing keys in
> > XCAP (RFC 4825) which also uses XPath expressions to point at subparts
> > or subtrees of an XML document. You can certainly maintain a unique key
> > within a list which is not generated from the data in each record.  Not
> > doing so "won't scale and would be very difficult to maintain".
> > However, this argument is orthogonal to our main topic.
> >
> >
> >      > Below, I also show examples of the YANG concepts of leaf node,
> >      > leaf-list, container, and list expressed in YANG, how it would be
> >      > expressed in NETCONF, and expressed in RELAX NG.
> >
> >     Here's another one:
> >
> >     in module foo:
> >
> >       rpc my-rpc {
> >         input {
> >           leaf foo { type string; }
> >         }
> >         output {
> >           leaf-list bar { type int32; }
> >           leaf baz      { type int32; }
> >         }
> >       }
> >
> >     in module bar:
> >
> >      augment /foo:my-rpc/foo:output {
> >         leaf data { type int32; }
> >      }
> >
> >
> >     How would this translate to RelaxNG?
> >
> >
> > I am assuming that this would generate the following XML in Netconf:
> > <rpc message-id="45">
> >   <my-rpc>
> >     <foo>some string</foo>
> >   </my-prc>
> > </rpc>
> >
> > <rpc-result message-id="45">
> >   <bar>4134</bar>
> >   <bar>3882</bar>
> >   <baz>112334</baz>
> >   <data>82382</data>
> > </rpc-result>
> >
> > I was not clear exactly the significance of "module foo" and "module
> > bar".  If I understood correctly, module foo defines the "my-rpc" RPC
> > call, and module bar just extends the response.  I will call these "
> > my-rpc.rng" and  "my-rpc-extension1.rng" respectively.
> >
> >
> > <!-- my-rpc.rng  -->
> > <include href="netconf-rpc.rng"/>
> >
> > <define name="rpc-requests" combine="choice">
> >   <ref name="my-rpc-request"/>
> > </define>
> >
> > <define name="rpc-responses" combine="choice">
> >   <ref name="my-rpc-response"/>
> > </define>
> >
> > <define name="my-rpc-request">
> >   <element name="foo">
> >     <data type="string"/>
> >   </element>
> >   <netconf:rpc-method type="request">my-rpc</netconf:rpc-method>
> > </define>
> >
> > <define name="my-rpc-response">
> >   <oneOrMore>
> >     <element name="bar">
> >       <data type="int"/>
> >     </element>
> >   </oneOrMore>
> >   <element name="baz">
> >     <data type="int"/>
> >   </element>
> >   <netconf:rpc-method type="response">my-rpc</netconf:rpc-method>
> > </define>
> >
> > Note that I used a Relax annotation to convey extra semantic data.  This
> > is ignored during relax syntax validation, but available to the
> > implementation if it wants to use this additional semantic information.
> > An example of this is described in the book in chapter 13.3:
> > http://books.xmlschemata.org/relaxng/relax-CHP-13-SECT-3.html
> >
> > The "augment" is accomplished using a define with interleave:
> >
> > <!-- my-rpc-extension1.rng -->
> >
> > <include href="my-rpc.rng"/>
> >
> > <define name="my-rpc-response" combine="interleave">
> >   <element name="data">
> >     <data type="int"/>
> >   </element>
> > </define>
> >
> > Finally, if you are allergic to angle brackets, you can do all this in
> > compact form as well:
> >
> > # my-rpc.rnc
> > include "netconf-rpc.rnc"
> > rpc-requests |= element foo { xsd:string }
> > rpc-responses |= {
> >   element bar { xsd:int }+,
> >   element baz { xsd:int }
> > }
> >
> > # my-rpc-extension1.rnc
> > include "my-rpc.rnc"
> > my-rpc-response &= element data { xsd:int }
> >
> >
> > For a more full example, I invite you to look at how Jari Urpalainen did
> > this for the PIDF family of XML schemas to allow full automatic syntax
> > validation. While his draft is recently expired, I have archived a copy
> > here:
> >
> http://svn.resiprocate.org/rep/ietf-drafts/simple/draft-urpalainen-simple-presence-relaxng-03.txt
> > <
> http://svn.resiprocate.org/rep/ietf-drafts/simple/draft-urpalainen-simple-presence-relaxng-03.txt
> >
> >
> > Also section 10.2 "Merging Grammars" in the Relax NG book describes this
> > very nicely:
> > http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-2.html
> > <http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-2.html>
> >
> > thanks,
> > -rohan
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> TSP System Manager
> ECN: 831 7320                        Fax: [phone]
> Tel: [phone]     email: [e-mail]
>