Re: [YANG] import statement

Andy Bierman <ietf@andybierman.com> Sat, 03 May 2008 21:24 UTC

Return-Path: <yang-bounces@ietf.org>
X-Original-To: yang-archive@optimus.ietf.org
Delivered-To: ietfarch-yang-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51F113A6D73; Sat, 3 May 2008 14:24:18 -0700 (PDT)
X-Original-To: yang@core3.amsl.com
Delivered-To: yang@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA213A6D73 for <yang@core3.amsl.com>; Sat, 3 May 2008 14:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.513
X-Spam-Level:
X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_NJABL_PROXY=1.643]
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 rCafqHnncB-U for <yang@core3.amsl.com>; Sat, 3 May 2008 14:24:16 -0700 (PDT)
Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id E42DA3A6C52 for <yang@ietf.org>; Sat, 3 May 2008 14:24:15 -0700 (PDT)
Received: (qmail 52958 invoked from network); 3 May 2008 21:24:17 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 3 May 2008 21:24:15 -0000
X-YMail-OSG: 9nrrVkEVM1koOA2ZDDANMb0xujNeD0VuNaxcQT00pKpdL3TPQM7.6ZQC3GMAYMIGTH.fS8kJqqHgdS24gIn3_QXRSmu3MJhWJuzAwQFKkuw5bp2c1FxH4OcGQY6VKGN1R_k-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <481CD7FD.5060107@andybierman.com>
Date: Sat, 03 May 2008 14:24:13 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Ladislav Lhotka <lhotka@cesnet.cz>
References: <1209840281.14759.57.camel@missotis> <20080503.211049.33022544.mbj@tail-f.com> <1209845563.14759.70.camel@missotis> <20080503.222459.40411510.mbj@tail-f.com> <1209849048.14759.97.camel@missotis>
In-Reply-To: <1209849048.14759.97.camel@missotis>
Cc: yang@ietf.org
Subject: Re: [YANG] import statement
X-BeenThere: yang@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: YANG modeling Language for NETCONF <yang.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yang>, <mailto:yang-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/yang>
List-Post: <mailto:yang@ietf.org>
List-Help: <mailto:yang-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang>, <mailto:yang-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: yang-bounces@ietf.org
Errors-To: yang-bounces@ietf.org

Ladislav Lhotka wrote:
> Martin Bjorklund píše v So 03. 05. 2008 v 22:24 +0200:
>>> Then augment performs two fundamentally different things  
>> I don't agree.  Why?
>>
> 
> With the absolute argument, augment inserts something carrying its own
> namespace in between foreign namespace nodes. In particular, no name
> conflicts can ever happen.
> 
> With uses and the descendant form of augment, you are first adopting
> something to your namespace and then modifying it. Names can clash here.
> For example, the author of the imported module may add an optional node
> to a grouping that from his point of view is perfectly backward
> compatible change. This may however break the importing module if a node
> added by augment happens to have the same name and is added at the same
> place.
> 
> The syntax
> 
>   uses foo:bar {
>     augment baz {
>      ...
>     }
>   }
>   uses boo:hoo;
> 
> has at least the advantage that it doesn't matter if boo:hoo uses baz.
> 

no -

If grouping 'boo:hoo' has a top-level node named 'baz' in it,
it will clash no matter where these clauses are placed.

Remember that a 'uses-stmt' does not add any containment,
and neither does the grouping being referenced.
Choices and cases do not add any containment.

All the child nodes of these constructs can clash, and the
compiler needs to generate a fatal error if that happens.


> Lada
> 

Andy

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www.ietf.org/mailman/listinfo/yang