Re: analysis of YANG vs. RELAX NG

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Nov 29, 2007 at 11:00:55AM -0800, Rohan Mahy wrote:
 
> 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.

Perhaps it helps me if you can define what you consider syntactic and
what semantic. Having your definition will help me to understand what
you have in mind and where you draw the line.

I must note that types have been extremely successful in terms of
actual reuse in the SMI world. You may consider data types "gratuitous
syntax" but they are damn useful from our experience in writing data
models.
 
> 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).

There are specific reasons why YANG does not support white space
separated lists. I am sure Phil is happy to tell you how much fun
these white space separated values can be and why we prefer to have
every value within its own element in an instance document. (Well,
actually even RFC 4741 states that subtree filtering on list content
and mixed content is not supported.)

I have been involved in a project where we tried to develop a data
modelling language (called SMIng) that is protocol independent. From
this experience, I have serious doubts that semantics decoupled from
syntax will work anytime soon. There are relative obvious issues where
for example the underlying naming system impacts the way you can
formulate expressions.  And then there are issues that only pop up
once you really do it in practice, e.g. dealing with exceptions or
errors. (In YANG, you can say that a violation of a given constraint
leads to a specific NETCONF error report. Once you all do this in a
decoupled semantics layer, you end up having to abstract the
error/exception reporting mechanisms, which in my experience does not
make the result necessarily easier to use). My personal eye opener in
the SMIng project happened when started to move from toy examples to
model something of moderate complexity (we picked DiffServ at that
time because it actually has a nice informal information model plus a
MIB module which does supports configuration).

But don't get me wrong, I do not want to discourage anyone from trying
it - perhaps there are people who can solve this challenge. My only
concern is that it will take years to get it done with no clear signs
upfront that it will actually work. The YANG mission is much less
ambitious and down to earth, simply driven by the goal to create a
vendor independent domain specific data modeling languages that can
replace proprietary solutions that have already been created.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>