Re: analysis of YANG vs. RELAX NG

[Balazs Lengyel <[e-mail]>]

Hello Rohan,
Further comments below.
regards Balazs

Rohan Mahy wrote:

>     - what is considered a compatible or incompatible change
> 
> 
> I believe I already covered this. Adding an additional choice (adding a 
> new rpc method), adding via interleave (adding additional data within a 
> container), and copying and redefining via restriction or addition 
> (reusing parts of one container for a new container) are all pretty easy.
[BALAZS]: So if I change the default value of a leaf/attribute is that compatible? Do I have to 
rename my model in this case? If I extend/restrict the value range of a variable is that 
compatible?
I see a number of questions here that are not obvious for me. I feel they need work.
>  
> 
>     - ordering of items within list, leaf-lists
> 
> 
> The schema I described preserves ordering.
[BALAZS]: Yes but is that the order in which the user inputs the leafs, or some order defined 
by the system? If it is user defined how do you insert in the middle.  For me your answer is 
not complete. As we say in Hungary: "The devil lurks in the details. And there are many little 
devils still hiding here.
 >
>     - differentiating between RPCs, notifications and data containers
>     (in YANG you have separate
>     statements)
> 
> 
> This is easy to do using pure syntax.  As in my example, to add an RPC 
> method or response, you just "combine with choice" and you insure that 
> the method isn't used as a notification or a data container.
[BALAZS]: yes but more work
> 
>     - Netconf specific error messages
> 
> 
> If you are talking about error messages sent on the wire, this is a 
> syntactic issue that Relax can handle out of the box.
[BALAZS]: I mean questions like what will be the content of the <error-app-tag> NETCONF element 
be on the wire, if the uniqueness constraint on interface names is violated? By the way how do 
you declare it in RelaxNg that interface names must be unique?
>  
> 
>     One important advantage of YANG is that the number of features in
>     YANG is much smaller then in
>     RelaxNg. 
> 
> 
> This is a preposterous statement. There is no need for an operator to 
> learn features of Relax (or XSD even) that they will never use in order 
> to read and write schema. 
[BALAZS]: I agree that there is no need to learn RelaxNg fully. But there are some dangerous 
constructs in RelaxNg that they need to understand e.g. like redefining patterns. Or is this 
not a problem?
>     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.
> 
> 
> I disagree. It looks like you have lots of implicit little rules in the 
> YANG draft. A network management person might have become desensitized 
> to these rules to the point of not noticing them, but they are there and 
> there are plenty of them.
>
[BALAZS]: Could you please list YANG's  implicit little rules. We will try to remove as many as 
possible.

regards Balazs