Re: [YANG] import statement

Ladislav Lhotka <lhotka@cesnet.cz> Sun, 04 May 2008 07:05 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 BA38328C220; Sun, 4 May 2008 00:05:28 -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 B27EA28C1A6 for <yang@core3.amsl.com>; Sun, 4 May 2008 00:05:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.713
X-Spam-Level:
X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_33=0.6]
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 bVr-QdVfhTuL for <yang@core3.amsl.com>; Sun, 4 May 2008 00:05:23 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id ED3B128C285 for <yang@ietf.org>; Sun, 4 May 2008 00:05:06 -0700 (PDT)
Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A9371D800C5 for <yang@ietf.org>; Sun, 4 May 2008 09:05:07 +0200 (CEST)
From: Ladislav Lhotka <lhotka@cesnet.cz>
To: yang@ietf.org
In-Reply-To: <20080503.232124.70324721.mbj@tail-f.com>
References: <1209845563.14759.70.camel@missotis> <20080503.222459.40411510.mbj@tail-f.com> <1209849048.14759.97.camel@missotis> <20080503.232124.70324721.mbj@tail-f.com>
Organization: CESNET
Date: Sun, 04 May 2008 09:05:06 +0200
Message-Id: <1209884706.15926.15.camel@missotis>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1
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

Martin Bjorklund píše v So 03. 05. 2008 v 23:21 +0200:

> 
> This is more an effect of how uses work than how augment works.

Yes and no - in this case augment makes very little sense without the
corresponding use statement. Effectively, the semantics of the two cases
are:

1. Reuse a foreign grouping in the local module, with optional 
   modifications.

2. Modify a schema tree (non-grouping) node in the foreign model.

Is it right that with 1 the device normally wouldn't advertise the
imported URI along with the local URI in hello? In case 2 it has to
since the absolute form of augment has otherwise no effect.

RELAX NG has an extension construct that is almost identical to 1, but
no equivalent for 2.

> Consider this case:
> 
>    uses foo:bar;
>    uses goo:baz;
> 
> If foo:bar contains container 'a' and goo:baz container 'b',
> everything is fine.  Now, if foo is updated and a container 'b' is
> added to the bar grouping, there will be a name collision in my
> module.

True, but here the collision can only occur at the top level of both
groupings, which is not very likely and easy to spot,  whereas augment
can descend to any depth of the grouping hierarchy and cause the
conflict there.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

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