Subject: [netmod] prefixes in groupings example

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Jul 2009 07:50:14 -0700

Hi,

I created 2 test modules (see attached) to see how
yangdump would deal with it.

Since the grouping 'ggg' is not actually used in module testfoo1,
it does not cause any errors or even warnings.

The error shows up via the uses-stmt in the testfoo2 module.
(Note the bug -- line number, line position (12.10)
is from testfoo1.yang file, not the testfoo2.yang
module that is currently being parsed.   Not sure how to report
this, since there is no error in testfoo1.yang:

    Error: Module for prefix 'foo' not found
    testfoo2.yang:12.10: error(228): invalid name

    *** /home/andy/modules/test/testfoo2.yang: 1 Errors, 0 Warnings

I don't really understand the current solution proposal.
Maybe somebody can write it down in sufficient detail
so I know for every possible usage of a prefix, or usage
of a QName identifier that does not have a prefix, and all
the special ways a YANG complier is supposed to interpret
the same syntax in various contexts.

I am concerned that groupings may be too fragile for reasonable
usage by people other than the standards writers.  Will a normal
engineer or operator study the 113 page YANG RFC thoroughly enough to
avoid making mistakes with groupings?  Is there sufficiently low
localized cost across all language features,
or is the overall complexity too high, in order to support
some corner-case features?  (I'm just asking, who knows...)

Andy

module testfoo1 {

    namespace "http://example.net/testfoo1";
    prefix "foo";

    revision 2009-07-28 {
        description "Initial revision.";
    }

    grouping ggg {
       container test-top {
         must "foo:bar < 42";
         leaf bar { type uint8; }
      }
   }

}
module testfoo2 {

    namespace "http://example.net/testfoo2";
    prefix "foo2";

    import testfoo1 { prefix foo1; }

    revision 2009-07-28 {
        description "Initial revision.";
    }

    container one {
        uses foo1:ggg;
    }
}

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 30 Jul 2009 11:50:07 +0200

>     *** /home/andy/modules/test/testfoo2.yang: 1 Errors, 0 Warnings

Can you trace down why the program thinks it's an error? I presume
prefixed names of types appearing inside a grouping in an imported
module are OK. Prefixed names in XPath expressions should be handled the
same way.
 
> the same syntax in various contexts.

Yes, this is necessary, I think we can do it together with Martin.

Lada

> Prostý textový dokument příloha (testfoo1.yang)
> module testfoo1 {
> 
> Prostý textový dokument příloha (testfoo2.yang)
> module testfoo2 {
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Jul 2009 13:20:59 -0700

> Yes, this is necessary, I think we can do it together with Martin.

I updated my example to show some of the ambiguities
that need to be cleared up.

It would be nice if there was a simple consistent rule
that applied to all statements, inside or outside a grouping,
and regardless of which module contains the uses-stmt.

Andy

module testfoo1 {

    revision 2009-07-28 {

    typedef MyType {
       type int32;
    }

    identity MyBase;

    identity my-identity {
       base MyBase;
    }

    grouping ggg {
       container test-top {
         must "foo:bar < 42";
         leaf bar { type uint8; }
         leaf baz { 
             must "../goo = 'my-identity'";
             type MyType;
         }
         leaf goo { 
            type identityref {
               base MyBase;
            }
            default my-identity;
         }
      }
   }

}
module testfoo2 {

    revision 2009-07-28 {

    typedef MyType {
       type boolean;
    }

    identity my-identity {
       base foo1:MyBase;
    }

    container one {
        uses foo1:ggg;
    }
}

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 31 Jul 2009 16:55:15 +0200 (CEST)

> and regardless of which module contains the uses-stmt.

This is what we came up with:

   o  The set of namespace declarations is the set of all "import"
      statements' prefix and namespace pairs in the module where the
      XPath expression is specified, and the "prefix" statement's prefix
      for the "namespace" statement's URI.

This says that the prefix is bound to a namespace in the module where
the must/when expression occurs.

   o  Names without a namespace prefix belong to the same namespace as
      the identifier of the current node.  Inside a grouping that
      namespace is affected by where the grouping is used (see
      Section 7.12).

And in section 7.12:

   The identifiers defined in the grouping are not bound to a namespace
   until the contents of the grouping are added to the schema tree via a
   "uses" statement that does not appear inside a "grouping" statement,
   a which point they are bound to the namespace of the current module.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 31 Jul 2009 11:47:28 +0200 (CEST)

And in section 7.12:

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 31 Jul 2009 09:07:22 -0700

>    a which point they are bound to the namespace of the current module.

This text does not fully address the example I posted (footest2.yang).

The problem is more complicated than just must/when expressions.

If the local prefix is not used (the normal use-case), then
the module with the uses-stmt will be used to find
identities and types, and resolve the default-stmt.
This is broken.

So the rule is very simple.
I think I heard Lada mention this over the audio feed.

For every QName referenced within the grouping:
  - the prefix MUST be used if the definition is outside the grouping
  - the prefix SHOULD NOT be used if the definition is inside the grouping
    (the exception is when the author really intends to force the
    grouping to be used within one module namespace.)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 31 Jul 2009 21:16:56 +0200 (CEST)

> identities and types, and resolve the default-stmt.

I agree that this would be broken.  But that is not how it works.  I
was a bit unclear in my quote of the proposed text -- the text was
from section 6.4.1, the XPath context, which applies to must/when/path
only.  Below I have attached the complete text for this section.  The
rules for non-xpath statements are the same as before.

/martin

6.4.1.  XPath Context

   All YANG XPath expressions share the following XPath context
   definition:

   o  The function library is the core function library defined in
      [XPATH], and a function "current()" which returns a node set with
      the initial context node.

   o  The set of variable bindings is empty.

   The mechanism for handling unprefixed names is adopted from XPath 2.0
   [XPATH2.0], and helps simplify XPath expressions in YANG.  No
   ambiguity may ever arise because YANG node identifiers are always
   qualified names with a non-null namespace URI.

   The context node varies with the YANG XPath expression, and is
   specified where the YANG statement with the XPath expression is
   defined.

7.12.  The uses Statement

   The "uses" statement is used to reference a "grouping" definition.
   It takes one argument, which is the name of the grouping.

   The effect of a "uses" reference to a grouping is that the nodes
   defined by the grouping are copied into the current schema tree, and
   then updated according to the refinement and augment statements.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 31 Jul 2009 12:28:36 -0700

> rules for non-xpath statements are the same as before.

how does this apply to types and identityrefs, and defaults?

   type foo:MyType;
   type MyType;

   default foo:my-identity;
   default my-identity;

   identity bar {
      base foo:MyBase;
   }
   identity bar {
      base MyBase;
   }

   type leafref {
      path ../foo:baz;
   }
   type leafref {
      path ../baz;
   }

Before, all of these statements that use QNames will use the
module that defined the statement as the local module,
to resolve the missing prefix .

Now these are all changing too, right?

Are you saying that some prefixes (or missing prefixes)
inside a grouping will mean one thing, and mean another
thing just inside must/when statements?

Andy