Re: analysis of YANG vs. RELAX NG
Phil Shafer <phil@juniper.net> Thu, 29 November 2007 16:53 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 1IxmdT-0007xw-PI; Thu, 29 Nov 2007 11:53:11 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxmdS-0007xW-Kl for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:53:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmdS-0007xL-BI for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:53:10 -0500
Received: from exprod7og112.obsmtp.com ([64.18.2.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxmdR-0006Yj-Rw for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:53:10 -0500
Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Thu, 29 Nov 2007 08:52:54 PST
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 08:51:48 -0800
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lATGplE44251; Thu, 29 Nov 2007 08:51:47 -0800 (PST) (envelope-from phil@idle.juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lATGmYsT048635; Thu, 29 Nov 2007 16:48:34 GMT (envelope-from phil@idle.juniper.net)
Message-Id: <200711291648.lATGmYsT048635@idle.juniper.net>
To: Rohan Mahy <rohan.mahy@gmail.com>
Subject: Re: analysis of YANG vs. RELAX NG
In-reply-to: <953beacc0711290824k50d781dfm21e06f3dcc898236@mail.gmail.com>
Date: Thu, 29 Nov 2007 11:48:34 -0500
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 29 Nov 2007 16:51:48.0067 (UTC) FILETIME=[21A8E330:01C832A8]
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
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
"Rohan Mahy" writes: >If you want to do strict validation of things like RPC methods on the >receiving implementation, the implementation can contain a list of all the >RPC methods it supports (an effective schema). If this level of validation >is not desired, we can ignore this concept. The issue isn't validation of the messages, but validation of the NETCONF datastore. We want to be modeling the data inside the NETCONF datastore, thinking more in terms of the object instances than the xml content being sent over the wire. XSD and RNG model the syntax of the xml content, not the semantics of the databases that NETCONF is building. If I say that a particular node is mandatory in the datastore, I'm not saying that it must appear in every XML RPC that's manipulating the datastore. If <b> is a mandatory leaf under <a>, I can perform an RPC that creates <c> under <a> without that RPC containing <b>. The validation tests are only meaningful to the complete data contents, not for individual RPCs. The constraints imposed by the YANG module definition must be complied with to have a valid configuration datastore, but do not apply to each <edit-config> operation. The semantics YANG provides are also important for defining the operations that are available over NETCONF. For example, when the order of entries in a list are maintained in an order defined by the user, you use YANG's "ordered-by user" statement to indicate that the list entries can be modified using the "insert" attribute. And saying that a container is operational data (rather than configuration) tells me that this container will be in the output of a suitable <get> RPC, within the proper hierarchy and keys defined in the YANG module. With YANG, I don't need distinct schemas to describe the scenarios where I traffic my YANG module's data, if I drive my validation from a YANG-enabled parser. But I can derive those schemas from my YANG module as needed. In many respects, YANG is similar to the approach of WSDL and WADL, which puts high-level concepts in specific high-level statements, but allows easy translation to XML schema languages. You can think of YANG as an IDL for NETCONF, but it does considerably more, in terms of modeling the configuration. Thanks, Phil
- analysis of YANG vs. RELAX NG Rohan Mahy
- Re: analysis of YANG vs. RELAX NG Martin Bjorklund
- Re: analysis of YANG vs. RELAX NG Leif Johansson
- Re: analysis of YANG vs. RELAX NG Juergen Schoenwaelder
- Re: analysis of YANG vs. RELAX NG Juergen Schoenwaelder
- Re: analysis of YANG vs. RELAX NG Paul Hoffman
- RE: analysis of YANG vs. RELAX NG Natale, Bob
- Re: analysis of YANG vs. RELAX NG Lisa Dusseault
- Re: analysis of YANG vs. RELAX NG Rohan Mahy
- Re: analysis of YANG vs. RELAX NG Juergen Schoenwaelder
- RE: analysis of YANG vs. RELAX NG Romascanu, Dan (Dan)
- Re: analysis of YANG vs. RELAX NG Leif Johansson
- RE: analysis of YANG vs. RELAX NG Romascanu, Dan (Dan)
- Re: analysis of YANG vs. RELAX NG Martin Bjorklund
- Re: analysis of YANG vs. RELAX NG Jon Saperia
- Do we need a formalized language: [Was: Re: analy… Balazs Lengyel
- Re: analysis of YANG vs. RELAX NG Balazs Lengyel
- Re: analysis of YANG vs. RELAX NG Rohan Mahy
- Re: analysis of YANG vs. RELAX NG Martin Bjorklund
- Re: analysis of YANG vs. RELAX NG Rohan Mahy
- Re: analysis of YANG vs. RELAX NG Juergen Schoenwaelder
- Re: analysis of YANG vs. RELAX NG Martin Bjorklund
- Re: analysis of YANG vs. RELAX NG Lisa Dusseault
- Re: analysis of YANG vs. RELAX NG Rohan Mahy
- Re: analysis of YANG vs. RELAX NG Juergen Schoenwaelder
- Re: analysis of YANG vs. RELAX NG Phil Shafer
- Re: analysis of YANG vs. RELAX NG Juergen Schoenwaelder
- Re: analysis of YANG vs. RELAX NG Balazs Lengyel
- Re: analysis of YANG vs. RELAX NG Balazs Lengyel
- Re: analysis of YANG vs. RELAX NG Balazs Lengyel
- Re: analysis of YANG vs. RELAX NG Balazs Lengyel
- Re: analysis of YANG vs. RELAX NG Andrew Newton
- Re: analysis of YANG vs. RELAX NG Rohan Mahy
- Re: analysis of YANG vs. RELAX NG Rohan Mahy
- Re: analysis of YANG vs. RELAX NG Balazs Lengyel
- Re: analysis of YANG vs. RELAX NG Rohan Mahy
- Re: analysis of YANG vs. RELAX NG Randy Presuhn
- Re: analysis of YANG vs. RELAX NG Juergen Schoenwaelder
- Re: analysis of YANG vs. RELAX NG Martin Bjorklund
- Re: analysis of YANG vs. RELAX NG Andy Bierman
- Re: analysis of YANG vs. RELAX NG Julian Reschke
- Re: analysis of YANG vs. RELAX NG Tim Bray
- Re: analysis of YANG vs. RELAX NG Ladislav Lhotka
- Re: analysis of YANG vs. RELAX NG Juergen Schoenwaelder
- Re: analysis of YANG vs. RELAX NG Ladislav Lhotka
- Re: analysis of YANG vs. RELAX NG Juergen Schoenwaelder
- Re: analysis of YANG vs. RELAX NG Andy Bierman
- Re: analysis of YANG vs. RELAX NG Ladislav Lhotka
- Re: analysis of YANG vs. RELAX NG Andy Bierman
- Re: analysis of YANG vs. RELAX NG Randy Presuhn
- RE: analysis of YANG vs. RELAX NG David Harrington
- RE: analysis of YANG vs. RELAX NG Romascanu, Dan (Dan)
- Re: analysis of YANG vs. RELAX NG Ladislav Lhotka
- Re: analysis of YANG vs. RELAX NG Juergen Schoenwaelder
- Re: analysis of YANG vs. RELAX NG Balazs Lengyel