Re: analysis of YANG vs. RELAX NG

[Balazs Lengyel <[e-mail]>]

Hello,
I am no expert in RelaxNg but here are some thoughts why I like Yang better.

I have the feeling once you extend RelaxNg with all the necessary bits, half your statements 
will start with <other:xxx>.

There are many aspects that can be somewhat tricky and/or simply time consuming, and are 
missing from RelaxNg:
- what does a default mean for configuration data
- what is considered a compatible or incompatible change
- ordering of items within list, leaf-lists
- netconf edit-config semantics
- differentiating between configuration and operational data
- differentiating between RPCs, notifications and data containers (in YANG you have separate 
statements)
- connecting RPC request definitions with RPC reply definitions
- definition of more complex types (IpAddress, MacAddress, ZeroBasedCounter, etc.). Nothing 
special but work to do even for RelaxNg
- Netconf specific error messages

Certainly all these can be done as extensions to RelaxNg as well, but even after taking RelaxNg 
as your base, you still have a big work to do. And once your specification is complete you need 
to build custom tools to understand the <other:xxx> statements. (For YANG we already have 
tools. see http://www.yang-central.org/twiki/bin/view/Main/YangTools)

--------------------------------------------------------------------------------------------

For NETCONF readability by operators, untrained in modeling languages, is a crucial 
requirement. The question is after how many hours (not days) of training can an operator grok a 
YANG model or a RelaxNg model? I feel YANG is easier.

One important advantage of YANG is that the number of features in YANG is much smaller then in 
RelaxNg. If we would count the number of features excluding stuff that is missing from RelaxNg, 
   the difference would become even more pronounced.

Generally YANG uses the terminology that network management people are familiar with e.g. 
container, augment, configuration data. Learning the RelaxNg terminology takes time.

In the network management world there is a general dislike for so called "little rules". Things 
like
- you can use RelaxNg but don't use attributes
- you can use RelaxNg but don't use mixed pattern
- you can use RelaxNg but don't redefine or remove patterns

With RelaxNg we will need a number of such rules. With a problem specific solution - YANG - 
the number of such rules is minimal.

Balazs


Rohan Mahy wrote:
> Hi Martin,
> 
> More comments inline.
> 
> On Nov 27, 2007 4:03 AM, Martin Bjorklund <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Hi,
> 
>     "Rohan Mahy" <[e-mail] <mailto:[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.
[BALAZS]: Relax can say a number of things we don't need, but can't say a number of other 
things we do. If you have thousands of words for ice cream but no words for colors then your 
language is too big and too small at the same time.
> 
>     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 
> <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 
> <http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-2.html>
> 
> thanks,
> -rohan

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: [phone]
Tel: [phone]     email: [e-mail]