Re: analysis of YANG vs. RELAX NG

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

On Nov 29, 2007 1:17 AM, Balazs Lengyel <[e-mail]> wrote:

> Hello Rohan,
> Thanks for your response. Here are some replies.
> Balazs
>
> Rohan Mahy wrote:
> ...
> > 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.
> [BALAZS]: Yes but if you need to extend RelaxNg, you loose much/most of
> the advantage of using
> a standard language. As we agreed all the extensions will need custom
> tools. These tools are
> already available for Yang, but not for RelaxNg. The experience with
> SNMP/SMI tools in the last
> decades also tells us that at the end nearly all SNMP tools were custom
> built and not based on
> standard ASN.1 tools. So the gain of following the standard is even more
> limited.
> > 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.
> >
> [BALAZS]: Yes, you recognized one of our main points: NETCONF needs
> semantics and processing
> rules. These have to be defined. Current schema languages don really do
> this. Thats one of our
> reasons to do YANG.
> A quote from the book RelaxNg by Eric van der List you recommended:
>
> "XML reintroduces a clean separation between data and processing. "


yes

However Netconf does need rules about processing,


yes


> so RelaxNg is not enough for us.


This does not logically follow.  You need chocolate and you need peanut
butter, but it does not follow logically that you need a Reese's Peanut
Butter Cup.

I am proposing that you could combine syntax and semantics, or you can layer
one on top of the other. Right now YANG is neither pure semantics, nor pure
syntax. For example the distinction between the leaf-list and list objects
in YANG is pretty syntactic. (One of the YANG team's "little-rules").
Likewise, creating containers automatically is a syntactic construction.
(Another "little-rule", but at least this one is explicit). Defining new
data types in YANG is completely gratuitous syntax.

I think having semantics for configuration information in general would be a
boon for the IETF, as we have several protocol that are used for
configuration.  Providing a way to describe semantics of common
configuration concepts like default values, list keys, constraints among
non-parent-child objects, all looks like great work to me, but I don't want
to this so tied to NETCONF that I cannot use it elsewhere for other
configuration data.

I also don't want this rigidly attached to a specific syntax either.  A lot
of existing XML-based data formats use attributes extensively. Some
XML-based languages (ex: GML) implement the equivalent of leaf-list using a
single attribute with whitespace separated values (there is even a built-in
data type (called "list") to handle this case).

thanks,
-rohan


We can
> reintroduce processing hints into RelaxNg, but is that still RelaxNg.
> Processing features
> needed include:
> - handling semantics of NETCONF edit-config
> - the meaning of default data for operational and configuration data
> - ordering of list data
> - automatic creation of some data (containers)
> - placement of data in normal structures, notifications or RPCs
> - others ???
>




> >
> > 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.
> >
> [BALAZS]: Yes as the above quote says it is NOT the implementors but the
> readers i.e. network
> operators that are important. I think they are much more familiar with the
> concept of a managed
> object or a list then "Pattern Compositions".
>