Re: analysis of YANG vs. RELAX NG

[Martin Bjorklund <[e-mail]>]

Hi,

"Rohan Mahy" <[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.

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.

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

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.

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.

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



/martin