Subject: Re: [netmod] definitions

From: "tom.petch" <[email-masked]>
Date: Wed, 3 Jun 2009 19:06:24 +0200

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, May 22, 2009 3:15 PM

> Ladislav Lhotka <[email-masked]> wrote:
> > Martin Bjorklund píše v Čt 21. 05. 2009 v 21:37 +0200:
> > > The text says:
> > >
> > >   The "import" statement makes definitions from one module available
> > >   inside another module or submodule.
> > >
> > > Could you propose text to make it more clear?
> >
> > The "import" statement makes identifiers from the namespace of the
> > imported module available in the importing module. In particular, the
> > importing module may
> >
> > o use groupings and typedefs defined at the top level of the imported
> >   module;
> >
> > o refer to features defined in the imported module;
> >
> > o use any data node of the imported module as the target node for the
> >   "augment" statement.
> >
> > Unlike "include", the "import" statement doesn't contribute the data
> > tree from the imported to the importing module.
>
> I'm not sure this text is better than the current text.  Does anyone
> else have an opinion?

Yes; both might be clearer:-(  The bulleted list is an improvement, but I do not
see "identifiers" as an improvement; it is more than identifiers, it is the
identity, the concept that is being identified.  Definitions is nearer the mark
but still, for me, understates what is on offer.

And in the last sentence, surely data tree is wrong; data node yes, but all in
the schema tree.

Tom Petch

> > > BTW, RNG doesn't have 'import' does it?
> >
> > It's called "include".
>
> Exactly.  YANG's include is more like RNG's include.  So I don't see
> why RNG users would be confused when YANG's import does not behave
> like RNG's include.
>
>
> /martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Jun 2009 09:39:42 +0200

> but still, for me, understates what is on offer.

Yes, but it is important to stress that the schema tree is not imported.
Can you suggest another formulation?

> And in the last sentence, surely data tree is wrong; data node yes, but all in

You are right.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Fri, 5 Jun 2009 11:23:28 +0200

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Martin Bjorklund" <[email-masked]>; <[email-masked]>
Sent: Thursday, June 04, 2009 9:39 AM
Subject: Re: [netmod] definitions

> Can you suggest another formulation?

I would go for 'objects' or 'entities' (or 'items') both of which have technical
meanings in some contexts, but also can safely be used more generically.

And add that phrase, giving

The "import" statement makes objects, but not the schema tree, from the
namespace of the imported module available in the importing module. In
particular, the importing module may:-

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Jun 2009 14:43:08 +0200 (CEST)

Hi,

> particular, the importing module may:-

I don't think "object" is a good word; it is not obvious that e.g. a
feature is an "object".  Also, I don't think it is accurate to say
that the schema tree is not available, since it is legal to refer to
nodes in the schema tree in e.g. augment.  So I suggest the following
compromise:

7.1.5.  The import Statement

   The "import" statement makes definitions from one module available
   inside another module or submodule.  The argument is the name of the
   module to import, and the statement is followed by a block of
   substatements that holds detailed import information.  When a module
   is imported, the importing module may:

   o  use any grouping and typedef defined at the top-level in the
      imported module or its submodules

   o  use any extension, feature, and identity defined in the imported
      module or its submodules

   o  use any node in the imported module's schema tree in augment,
      must, path, and when statements

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Jun 2009 09:26:53 -0700

Martin Bjorklund wrote:
> I don't think "object" is a good word; 

Agreed.
We should make sure that YANG and the Usage Guidelines drafts
use consistent and deliberate terminology.  I like the
current 'data node' and 'schema node', but they are not 1:1
and that is important to remember.

I like the term "YANG content" to refer to anything in a
NETCONF PDU that YANG covers (rpc, rpc-reply, notification
content).  The term 'data node' is just for a YANG-accessible
XML element which is (conceptually) contained within
a NETCONF configuration database.

The term "YANG-accessible" refers to the XML (PDU) nodes which NETCONF/YANG
operations MUST be supported.  The contents of an 'anyxml' node,
as well as any XML attributes outside the YANG and NETCONF namespaces,
are not YANG-accessible.

it is not obvious that e.g. a
>       must, path, and when statements

this is good

> /martin

Andy

---

From: "tom.petch" <[email-masked]>
Date: Tue, 23 Jun 2009 15:01:48 +0200

---- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, June 22, 2009 2:43 PM
Subject: Re: [netmod] definitions

> > > > Yes; both might be clearer:-( The bulleted list is an improvement, but I
do
> > not
> > > > identity, the concept that is being identified.  Definitions is nearer
the
> > mark

ok, good enough

Tom Petch