Re: analysis of YANG vs. RELAX NG

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

Hi Martin,

More comments inline.

On Nov 27, 2007 4:03 AM, Martin Bjorklund <[e-mail]> wrote:

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


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

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

thanks,
-rohan