Re: analysis of YANG vs. RELAX NG

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 29 November 2007 08:16 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 1IxeZ7-00007N-E6; Thu, 29 Nov 2007 03:16:09 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxeZ6-0008U3-Aq for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 03:16:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxeZ5-0008Rq-R3 for discuss@apps.ietf.org; Thu, 29 Nov 2007 03:16:07 -0500
Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxeZ5-0006CE-7l for discuss@apps.ietf.org; Thu, 29 Nov 2007 03:16:07 -0500
Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E0F58A1CF; Thu, 29 Nov 2007 09:16:06 +0100 (CET)
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 21500-10; Thu, 29 Nov 2007 09:16:01 +0100 (CET)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 476678A116; Thu, 29 Nov 2007 09:16:01 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 13D44401EDC; Thu, 29 Nov 2007 09:16:01 +0100 (CET)
Date: Thu, 29 Nov 2007 09:16:00 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: analysis of YANG vs. RELAX NG
Message-ID: <20071129081600.GC10453@elstar.local>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org>
User-Agent: Mutt/1.5.17 (2007-11-01)
X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: discuss@apps.ietf.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@jacobs-university.de
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

On Wed, Nov 28, 2007 at 03:34:06PM -0800, Lisa Dusseault wrote:
> This is another aspect I'd like to understand better:
>
> On Nov 28, 2007, at 2:02 PM, Martin Bjorklund wrote:
>
>> 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.
>
> Validating XML really limits the customizability, the very extensibility of 
> the XML.  You can't add so much as a <custom-text-description> or 
> <debug-info-only> element without it failing at the other end.  Is the goal 
> here to strictly limit netconf data to only standardized and implemented 
> schemas?

The point Martin and Any were trying to make is that validation
against a schema within a NETCONF implementation does not make too
much sense; you have to validate the data exchanged against the
datastore. And the implementations we are aware of do this without
using generix XML schema validators.

And yes, since we are talking about configuration, we do expect that
easy support for vendor extensions is crucial.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>