Re: Why NETCONF needs a data modeling language

[Martin Bjorklund <[e-mail]>]

Hi Rohan,

"Rohan Mahy" <[e-mail]> wrote:
> Look at the following Relax NG in compact form, side-by-side with YANG.
> 
> container aaa {
>    container bbb {
>       leaf foo { type string; }
>       leaf bar { type uint32; }
>    }
> }
> 
> element aaa {
>    element bbb {
>       element foo { xsd:string },
>       element bar { xsd:unsignedInt }
>    }
> }
> 
> This hardly seems like a big difference to me.

I take the liberty to slightly modify this example into:

    container aaa {
      container bbb {
        leaf ifAdminStatus {
          type string;
          description
            "The desired state of the interface.";
          mandatory true;
        }
        leaf ifOperStatus {
          type string;
          description
            "The current operational state of the interface.";
          config false;
        }
      }      
    }
    
It's still a bit simplified, e.g. the type is just a string; it should
really be an enumeration.

The plain RNC is then:

    element aaa {
      element bbb {
        element ifAdminStatus { type xsd:string }?,
        element ifOperStatus  { type xsd:string }?
      }
    }

First of all, these two examples may look similar, but they have
different meaning.  The YANG example defines objects in the
(configuration) data tree.  The RelaxNG example defines a pattern
which is used to validate some XML instance document.

Anyway, if we want to make this RNC as extensible as the corresponding
YANG version, we follow the recommendations in chapter 12 of the book:

    element aaa = aaa-content
    
    aaa-content =
      element bbb {
        bbb-content
      }
    
    bbb-content =
      element ifAdminStatus {
        ifAdminStatus-content
      }?,
      element ifOperStatus {
        ifOperStatus-content
      }?
    
    ifAdminStatus-content =
      type xsd:string
    
    ifOperStatus-content =
      type xsd:string

Next, we add the YANG specific annotations:

    element aaa = aaa-content
    
    aaa-content =
      element bbb {
        bbb-content
      }
    
    bbb-content =
      [
        yang:mandatory [ "true" ]
        yang:description [ "The desired state of the interface." ]
      ]
      element ifAdminStatus {
        ifAdminStatus-content
      }?,
      [
        yang:description [ 
          "The current operational state of the interface."
        ]
      ]
      element ifOperStatus {
        ifOperStatus-content
      }? >> yang:config [ "false" ] # I don't know if initial or
                                    # following annotations are
                                    # better (or even equal). 
    
    ifAdminStatus-content =
      type xsd:string
    
    ifOperStatus-content =
      type xsd:string
    

This is starting to become a bit difficult to grasp at first sight.
Maybe we should follow the recommendation in the book and work with
the XML notation instead.

On a higher level, what exactly is the interpretation of adding
e.g. the yang:mandatory true annotation to ifAdminStatus?  The annotation
is added to the pattern which matches the xml element <ifAdminStatus>.
But that is just the encoding of the underlying object.  What happens
with this annotation if ifAdminStatus is not present in an instance
document?  Should we modify the meaning of the RelaxNG patterns and
say that they also somehow define objects in the configuration data
tree?

This schema will validate <get> replies only, since it contains both
config and non-config data.  According to your email, we'll have to
add these to the definitions of get, get-config, edit-config, and
copy-config:

   get-reply-content &=
     aaa

   get-config-reply-content &=
     # hmm... how do I do this w/o copy&paste?  I just want
     # to add aaa/bbb/ifAdminstatus.

   edit-config-content &=
     # hmm... how do I do this w/o copy&paste?  I just want
     # to add aaa/bbb/ifAdminstatus, but also add some nc:opertaion
     # attributes.


All of this (and the other things we've discussed (and the things we
haven't yet discussed :) ) can probably be solved by writing rules to
restrict the usage of RelaxNG, add the necessary annotations (around
20), and write down extra interpretion of the RelaxNG constructs we're
using, but my conclusion is the same as Juergen's list a-d in his
latest email.  To this list I'd like to add the readibility issue.  


/martin