Re: analysis of YANG vs. RELAX NG

[Balazs Lengyel <[e-mail]>]

Hello Rohan,
Thanks for your response. Here are some replies.
Balazs

Rohan Mahy wrote:
...
> 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.  
[BALAZS]: Yes but if you need to extend RelaxNg, you loose much/most of the advantage of using 
a standard language. As we agreed all the extensions will need custom tools. These tools are 
already available for Yang, but not for RelaxNg. The experience with SNMP/SMI tools in the last 
decades also tells us that at the end nearly all SNMP tools were custom built and not based on 
standard ASN.1 tools. So the gain of following the standard is even more limited.
> We can even write 
> schema which describes what syntax is allowed for these annotations in a 
> netconf-semantics namespace.
>  
> 
>     - what does a default mean for configuration data
> 
> 
> this is semantic.
>  
[BALAZS]: Yes, you recognized one of our main points: NETCONF needs semantics and processing 
rules. These have to be defined. Current schema languages don really do this. Thats one of our 
reasons to do YANG.
A quote from the book RelaxNg by Eric van der List you recommended:

"XML reintroduces a clean separation between data and processing. "

However Netconf does need rules about processing, so RelaxNg is not enough for us. We can 
reintroduce processing hints into RelaxNg, but is that still RelaxNg. Processing features 
needed include:
- handling semantics of NETCONF edit-config
- the meaning of default data for operational and configuration data
- ordering of list data
- automatic creation of some data (containers)
- placement of data in normal structures, notifications or RPCs
- others ???


> 
> Maybe I have different implementors, but the implementor is more likely 
> to have some XML experience than to be a "network management person".  
> Following the principle mentioned in Section 3.1 of 
> draft-schoenw-sming-lessons-01.txt, the implementor is a "reader" and 
> simplicity for the reader takes precedence:
> 
>    As a consequence, preference should be give to solutions that
>    simplify the task of readers.  Reduction of the efforts required by
>    writers is of secondary importance and the reduction of the efforts
>    required by tool developers is of least important preference.  While
>    this perhaps seems obvious, it is at times difficult to take
>    according design decisions, especially if the group working on a new
>    data modeling language is dominated by tool developers or data model
>    writers.
> 
[BALAZS]: Yes as the above quote says it is NOT the implementors but the readers i.e. network 
operators that are important. I think they are much more familiar with the concept of a managed 
object or a list then "Pattern Compositions".