Re: analysis of YANG vs. RELAX NG

Martin Bjorklund <mbj@tail-f.com> Wed, 28 November 2007 22:57 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVqv-0003JI-9t; Wed, 28 Nov 2007 17:57:57 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxVqu-0003JC-BD for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:57:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVqu-0003IK-0q for discuss@apps.ietf.org; Wed, 28 Nov 2007 17:57:56 -0500
Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxVqr-0008FW-Fl for discuss@apps.ietf.org; Wed, 28 Nov 2007 17:57:56 -0500
Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id 7ADFF1B80C5; Wed, 28 Nov 2007 23:57:52 +0100 (CET)
Date: Wed, 28 Nov 2007 23:57:50 +0100
Message-Id: <20071128.235750.175042294.mbj@tail-f.com>
To: rohan.mahy@gmail.com
Subject: Re: analysis of YANG vs. RELAX NG
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <953beacc0711281443h3624f486i96b30b9aa320e4f7@mail.gmail.com>
References: <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <953beacc0711281443h3624f486i96b30b9aa320e4f7@mail.gmail.com>
X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: discuss@apps.ietf.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

Hi,

"Rohan Mahy" <rohan.mahy@gmail.com> wrote:
> Hi Martin,
> 
> On Nov 28, 2007 2:02 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> > Hi,
> >
> > "Rohan Mahy" <rohan.mahy@gmail.com> wrote:
> > > Setting that aside for a moment, even if half the statements in a schema
> > are
> > > annotation, the other half can still do something very, very useful.
> >  They
> > > can validate the syntax and structure of the XML received on the wire
> > > automatically in a piece of code (the XML parser) that the
> > implementation
> > > probably already has.
> >
> > Note that in order to validate the different NETCONF messages, you
> > would either need more than one schema, or a very lax schema which
> > will validate messages/documents which are not actually valid NETCONF.
> > As one very simple example, suppose we have these in the data model:
> >
> >   leaf ifAdminStatus {
> >      config true;
> >      type ...;
> >   }
> >   leaf ifOperStatus {
> >      config false;
> >      type ...;
> >   }
> >
> > In a <get-config> only ifAdminStatus can occur.  In a <get> both can
> > occur.  In an <edit-config>, there can be an nc:operation attribute on
> > the ifAdminStatus, but that attribute cannot be present in a <get>.
> 
> 
> You can express this very easily like this:
> 
> <define name="get-config" combine="interleave">
>   <ref name="ifAdminStatus"/>
> </define>
> 
> <define name="get" combine="interleave">
>   <ref name="ifAdminStatus"/>
> </define>
> 
> <define name="get" combine="interleave">
>   <ref name="ifOperStatus"/>
> </define>
> 
> or in short form:
> 
> get-config &= ifAdminStatus
> get &= ifAdminStatus
> get &= ifOperStatus

But then you also have edit-config, where the nc:operation attribute
has to be added for ifAdminStatus, and you have copy-config where the
attribute must not be added.  So you would have to explicitly add each
leaf to these four rpcs...?  And I'm not even sure this approach would
work for deep structures, where some leafs are config and some are
not:
  
  container interfaces {
    leaf ifNumber { config false; type int32; }
    list interface {
      key ifIndex;
      leaf ifIndex { type uint32; }
      leaf ifAdminStatus { config true; ... }
      leaf ifOperStatus  { config false; ... }
      ...
    }
  }


/martin