Re: analysis of YANG vs. RELAX NG

[Martin Bjorklund <[e-mail]>]

Hi,

"Rohan Mahy" <[e-mail]> wrote:
> 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.

Note that in order to validate the different NETCONF messages, you
would either need more than one schema, or a very lax schema which
will validate messages/documents which are not actually valid NETCONF.
As one very simple example, suppose we have these in the data model:

   leaf ifAdminStatus {
      config true;
      type ...;
   }
   leaf ifOperStatus {
      config false;
      type ...;
   }

In a <get-config> only ifAdminStatus can occur.  In a <get> both can
occur.  In an <edit-config>, there can be an nc:operation attribute on
the ifAdminStatus, but that attribute cannot be present in a <get>.

> 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.

One such tool is available from www.yang-central.org.  It currently
supports a single XSD output, but adding e.g. RelaxNG should be
possible.  YANG is based on three different vendor-specific languages,
which all three have tools that generate XSD.

Three of the people in the YANG gang have existing NETCONF
implementations.  None of these implementations are actually using XSD
or RelaxNG to do validation in the parser, (partly) for the reasons
listed above.

[...]

> 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.

In my experience, people who design data models for device
configuration and monitoring do not typically think in terms of
patterns which match an XML instance document.  Instead they might
think in terms of objects with certain attributes, operations and
notifications, or in terms of a hierarchical structure of config
parameters.  From an operator perspective I also believe (although I
don't really know) that it's more common to think about which config
parameters can be set, than which patterns might match some virtual
XML instance document.  Thus, IMO a domain specific language with
a smaller semantic gap between the language and how people think about
and understand the problem will be more appropriate.



/martin