Re: analysis of YANG vs. RELAX NG

Andy Bierman <ietf@andybierman.com> Mon, 03 December 2007 17:23 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 1IzF10-0004AW-9J; Mon, 03 Dec 2007 12:23:30 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzF0y-0004AH-Ka for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 12:23:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzF0y-0004A7-Ax for discuss@apps.ietf.org; Mon, 03 Dec 2007 12:23:28 -0500
Received: from omr6.networksolutionsemail.com ([205.178.146.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzF0w-0001Pl-CG for discuss@apps.ietf.org; Mon, 03 Dec 2007 12:23:28 -0500
Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id lB3HNPdN026431 for <discuss@apps.ietf.org>; Mon, 3 Dec 2007 12:23:26 -0500
Received: (qmail 910 invoked by uid 78); 3 Dec 2007 17:23:25 -0000
Received: from unknown (HELO ?130.129.85.76?) (andy@andybierman.com@130.129.85.76) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 3 Dec 2007 17:23:25 -0000
Message-ID: <47543B30.1060409@andybierman.com>
Date: Mon, 03 Dec 2007 09:21:52 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: j.schoenwaelder@jacobs-university.de
Subject: Re: analysis of YANG vs. RELAX NG
References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> <47512728.6040201@gmx.de> <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> <1196690162.5874.13.camel@missotis> <20071203140846.GB17536@elstar.local>
In-Reply-To: <20071203140846.GB17536@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
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

Juergen Schoenwaelder wrote:
> On Mon, Dec 03, 2007 at 02:56:02PM +0100, Ladislav Lhotka wrote:
>   
>> Tim Bray p????e v Ne 02. 12. 2007 v 12:42 -0800:
>>     
>>> I've been staying off this thread because I don't understand what a
>>> NETCONF is or what you'd do with one.  But Julian's point is massively
>>> important.  If you're going to design your own modeling language, you
>>> need to spend a *lot* of time thinking about the extensibility model.
>>> It's really easy to get wrong.  -Tim
>>>       
>> Indeed. An extensibility problem in YANG is IMO the leaf statement. It
>> is encoded as an XML element but the fact that it is declared as leaf
>> effectively makes it into an XML attribute: It is impossible to extend
>> it (e.g., add a qualifying subelement) without changing the leaf into
>> container. In a RELAX NG schema, if properly designed, such an extension
>> wouldn't have to touch the parent schema.
>>     
>
> Leafs carry data and we strongly dislike mixed contents in NETCONF. So
> this is actually a YANG feature and not a bug.
>  
>   

I strongly agree with Juergen.
YANG is based (in part) on 18+ years experience
with SNMP and SMI.

It s absolutely forbidden in NM to redefine the syntax and semantics
of a managed object in this way.


Andy


>> Another problem might be the default statement in leaves (or it is
>> proper to say leafs here?:-) or typedefs. What if a standard data model
>> defines an item, say a hello timer, with such a default, but an
>> implementation wants to use another value for the default? Should it
>> come up with another schema?
>>     
>
> No. There can only be one standard default. If you are thinking about
> reusable groupings, then defaults can actually be changed wherever you
> apply a grouping as far as I know.
>
> /js
>
>