Re: analysis of YANG vs. RELAX NG

Martin Bjorklund <mbj@tail-f.com> Wed, 28 November 2007 13:56 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 1IxNOT-0007Gz-4B; Wed, 28 Nov 2007 08:56:01 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxNOR-0007GU-Fc for discuss-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:55:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNOR-0007GK-5H for discuss@apps.ietf.org; Wed, 28 Nov 2007 08:55:59 -0500
Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxNOO-0003G3-O7 for discuss@apps.ietf.org; Wed, 28 Nov 2007 08:55:59 -0500
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 8FA521B80CE; Wed, 28 Nov 2007 14:55:54 +0100 (CET)
Date: Wed, 28 Nov 2007 14:57:01 +0100
Message-Id: <20071128.145701.64447349.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: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com>
References: <20071127.130355.18118495.mbj@tail-f.com> <953beacc0711271504y7aea5f21jc301ccad886d3611@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: f4c2cf0bccc868e4cc88dace71fb3f44
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,
> 
> More comments inline.
> 
> On Nov 27, 2007 4:03 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> > Hi,
> >
> > "Rohan Mahy" <rohan.mahy@gmail.com> 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.

[...]

> 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.

Right.  I think we say that in the draft as well.  This can absolutely
be done, but for the reasons we have listed in the draft and in this
email thread so far, we think a better solution is to use a domain
specific language.  Note that YANG is not a XML schema language.  A
RelaxNG or XSD schema can be used to validate the NETCONF XML encoding
of the data, operations and notifications described in YANG modules.
(actually, you'd typically need more than one schema, depending on
which NETCONF operation you're validating - these can be generated by
the tools and fed into the XML parsers).

> > 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.

Absolutely.  This work has to be done anyway.

> 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.

Yes.



/martin