Re: [NGO] WG Review: NETCONF Data Modeling Language (netmod)

Phil Shafer <phil@juniper.net> Mon, 21 April 2008 15:58 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C81D3A6A0A; Mon, 21 Apr 2008 08:58:58 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5838A3A6F3B; Mon, 21 Apr 2008 05:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnhE18BGZs3Q; Mon, 21 Apr 2008 05:43:13 -0700 (PDT)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 5B72F3A6F38; Mon, 21 Apr 2008 05:43:13 -0700 (PDT)
Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Mon, 21 Apr 2008 05:43:18 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 05:42:49 -0700
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 m3LCglD26882; Mon, 21 Apr 2008 05:42:47 -0700 (PDT) (envelope-from phil@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 m3LCfDdM032961; Mon, 21 Apr 2008 12:41:13 GMT (envelope-from phil@idle.juniper.net)
Message-Id: <200804211241.m3LCfDdM032961@idle.juniper.net>
To: Chris Newman <Chris.Newman@Sun.COM>
Subject: Re: [NGO] WG Review: NETCONF Data Modeling Language (netmod)
In-reply-to: <D50248ED6D20DB444FD88CD1@446E7922C82D299DB29D899F>
Date: Mon, 21 Apr 2008 08:41:13 -0400
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 21 Apr 2008 12:42:49.0167 (UTC) FILETIME=[34DDA5F0:01C8A3AD]
X-Mailman-Approved-At: Mon, 21 Apr 2008 08:58:56 -0700
Cc: ngo@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Chris Newman writes:
>The simpler (5) 
>happens to be, the more confident I will become that YANG is following best 
>practices for XML DMLs.

My guess is the opposite:  many of the more useful features of XSD
and DSDL require distinct and uncomfortable layout of the schema
material.  For example, the XSD substitution group mechanism allows
for extensibility, but requires the schema to include substitution
group information pervasively throughout the schema and to make a
very shallow hierarchy through the use of types and indirection.
This gives a format that I believe non-validating consumers of the
schema will find difficult to read and use.

By contrast, YIN is a straight-forward conversion of the textual
data from a YANG module into an XML format that can be easily and
directly used by the consumer.  The conversion is trivia and the
information is in a state identical to the YANG module's layout.
The encoding is changed (to XML) but the content is untouched.

So if (5) is simple, we've either chosen not to use significant but
uncomfortable features in the low-level output language, or we've
lost the conciseness, hierarchical view, and other high-level features
that makes YANG worthwhile.

This isn't to say that (5) shouldn't be fairly mechanical, something
that a perl or xslt script could handle, but it shouldn't be called
simple, nor should the complexity of that transformation a basis
for judging YANG.

Thanks,
 Phil
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf