Subject: [netmod] belongs-to

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Aug 2008 09:05:08 +0200 (CEST)

Hi,

I believe it was Andy who pointed out that there is one thing which
breaks the rule that a submodule can be validated in isolation from
its main module.  The problem is the local prefix used for the module.
In a submodule, an XPath expression might use the module's local
prefix to refer to local nodes.  But the module's prefix is defined in
the main module.  This implies that a validator which validates a
submodule has to parse the main module as well, just to get to the
prefix.  It is also harder on the reader, since it is very implicit.

To solve this problem, I suggest we add an optional prefix
substatement to belongs-to:

  submodule foo {
    belongs-to bar {
      prefix b;
    }
    ...
  }

/martin
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Aug 2008 08:49:37 -0400

Martin Bjorklund writes:
>the main module.

Can we require that XPath expressions for the current namespace
not use a prefix?  It's more clear and less work.  Or is there
some case where you need the prefix?

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Aug 2008 15:00:17 +0200 (CEST)

> some case where you need the prefix?

Another use case which I forgot to mention is references to local
typedefs and groupings.  This can be solved in the same way of course
(by not allowing prefix on references to local definitions), but I
would prefer to let the user decide whether local definitions should
be prefixed or not.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Aug 2008 15:48:37 +0200 (CEST)

> would prefer to let the user decide whether local definitions should

Yet another use-case is references to extensions.  In this case, the
extension MUST have a prefix, even when it is local.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Aug 2008 06:51:22 -0700

> substatement to belongs-to:

It isn't that hard to read in the module header to get this info.
I agree it is confusing because the sub-module can use a prefix
that is not actually declared anywhere in the sub-module.
You need to maintain a context record anyway to detect
multi-module definition loops, so this is just a few mores
days of coding on top of that ;-)

I don't know that self-compiling sub-modules are important
for the standard.  You can never release just a sub-module.

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Aug 2008 15:59:15 +0200 (CEST)

...

> that is not actually declared anywhere in the sub-module.

This is the main problem.  I'm adding some clarifications that you
suggested earlier:

  - submodules must be self-contained -- if a foreign symbol is
    encountered (e.g., type or grouping name) then it must be
    found through the import or include mechanisms.

  - since a sub-module can never import or include its parent(s),
    it cannot use any definitions from those files.

  - the one exception to this rule is the module prefix, which
    may optionally be used within its submodules.  (This means
    a compiler parsing a sub-module must also partially parse
    the top module, via the belongs-to clause, to get the module prefix).

And I would like to avoid this one exception.  Everything will be
simpler if we keep the number of exceptions to a minimum, and the
resolution to this one seems pretty obvious and easy.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Aug 2008 07:36:29 -0700

> resolution to this one seems pretty obvious and easy.

The obvious solution is the one Phil suggested,
not adding yet another prefix variant into the module.
What if the module uses sub-module definitions in
Xpath with its own prefix, and all the sub-modules
use different prefixes as well -- it makes other tasks
like grouping/uses and augment processing more difficult.

(And yes, it is a pain to code this, but yangdump will
always allow the local prefix or no prefix -- even on extensions
in the local module.  And yes, I am annoyed, because I suggested
the 'no prefix on current module' rule a year ago :-)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Aug 2008 07:51:10 -0700

> the 'no prefix on current module' rule a year ago :-)

The reason for not doing this was that we could never add
any new built-in data types without incrementing the yang-version
to '2'.  IMO, so what?  Adding new built-in types is a major
change so bumping the YANG version is appropriate.

But I also think the current design is OK.
The belongs-to statement implies the module prefix.
Add some documentation and it won't be confusing anymore.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Aug 2008 10:48:10 -0400

Martin Bjorklund writes:
>typedefs and groupings.

Ah, right.  I'm fine with prefix inside belongs-to.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Aug 2008 14:24:16 +0200

> substatement to belongs-to:

Is this problem important enough to require the suggested solution?
What happens if the prefix declared in belongs-to is different from
the prefix declared in the module?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 18 Aug 2008 14:37:46 +0200 (CEST)

> Is this problem important enough to require the suggested solution?

Since solution is simple enough, yes.  It closes the only special rule
we have - with this there are no implicit dependencies.

> the prefix declared in the module?

Nothing.  Just as you can import with a different prefix than is used
in the imported module.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Aug 2008 14:55:54 +0200

> Nothing.  Just as you can import with a different prefix than is used

I assume the scope of the prefix b is restricted to the submodule,
right?  But something I define with prefix b does likely not make
sense in the module which has a different prefix, lets say a. In other
words, an implementation has to pay attention to the submodule prefix
since it may be different than the module prefix.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 18 Aug 2008 15:33:21 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> right?

Yes.

> But something I define with prefix b does likely not make

All prefixes are local to the module/submodule where they are declared
(in import).  An implementation must keep a prefix-to-module map per
module/submodule, and when a prefixed identifier is found, the map is
consulted to (i) make sure the prefix is declared, and (ii) check the
identifier in the module.

I'm not sure I addressed your concern though...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Aug 2008 07:11:22 -0700

> the prefix declared in the module?

IMO - NO.

What about include statements in sub-modules?
They have no prefix.  It is assumed that
all sub-modules share the same prefix.
If sub-module A uses 'foo' from sub-module B,
is is 'foo', 'A:foo', 'B:foo', or something new?
What if a 'B' is already imported into sub-A?

I do not like this solution proposal because the problem
is not really very hard to solve with code.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 18 Aug 2008 17:24:42 +0200

> some case where you need the prefix?

I have to reiterate that according to the XPath 1.0 no prefix means null
namespace. So accepting this convention breaks the XPath spec.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Aug 2008 08:40:47 -0700

> namespace. So accepting this convention breaks the XPath spec.

1) there is a prefix -- it is in the main module,
    indicated by the 'belongs-to'.  You get it from there.

2) We are defining the YANG spec, not the XPath spec.
    Part of the YANG spec defines the evaluation contexts
    that are used by a YANG compiler to process XPath expressions.
    It is perfectly valid for the already custom YANG context
    to declare that missing prefixes are replaced with the current
    module prefix, when evaluating the XPath expression,
    and when translating YANG to DSDL.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 18 Aug 2008 18:33:09 +0200 (CEST)

> all sub-modules share the same prefix.

Yes.  Specifying the prefix in belongs-to does not change this.

> is is 'foo', 'A:foo', 'B:foo', or something new?

It is either just 'foo' or 'x:foo' if x is the prefix from the
belongs-to.

> What if a 'B' is already imported into sub-A?

A submodule cannot be imported.

> is not really very hard to solve with code.

But it is hard to solve for the reader.  With this simple solution,
all prefixes are locally declared.  This is more clear and a win for
the reader.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Aug 2008 09:45:49 -0700

> all prefixes are locally declared.  This is more clear and a win for

IMO, it is not a win.
If each prefix represents a different namespace, that
is clear to the reader.  If 2 prefixes sometimes
indicate the same module and same namespace, then this
is confusing.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Aug 2008 10:18:47 -0700

> A submodule cannot be imported.

I meant included.

What happens if the optional 'prefix b;' is not present?
Does that mean the module prefix MUST NOT be used for
any local identifier (or any identifier from an 'include')?

Otherwise, the compiler (and reader) need to look at the
main module to get the prefix.

I do not mind this change if that rule was in place.
Add it to the list of complex prefix transformations
that a compiler needs to do when expanding augments and uses.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 18 Aug 2008 13:24:05 -0400

>namespace. So accepting this convention breaks the XPath spec.

But I think we get to say what the null namespace means in
our context.  I think this is fine.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 18 Aug 2008 22:06:56 +0200

>     indicated by the 'belongs-to'.  You get it from there.

Sec. 2.3 of the XPath 1.0 Recommendation: "if the QName does not have a
prefix, then the namespace URI is null". And QName is every individual
component of every XPath expression. Everyone who has been using
XPath/XSLT extensively must have been bitten by this already: There is
NO WAY to specify a context in which the concept of a default (non-null)
namespace can apply. Note that XPath 2.0 addresses this issue, probably
on popular demand.

> 2) We are defining the YANG spec, not the XPath spec.

It will take more than one paragraph to define "something like XPath". I
would prefer to use XPath 1.0 according to its spec and accept its
features that may be perceived as annoying. I think it wouldn't be that
bad after all - and perhaps it may help to clarify the use of XPath
expressions in augments etc.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Aug 2008 13:30:05 -0700

> expressions in augments etc.

I am not convinced.
It is not hard to know which is the current module
in your implementation.  It is therefore not hard
to insert the module prefix when it is missing.

I think the YANG to DSDL translation must account
for all sorts of prefix translations, this being one of them.
You are going to feed the DSDL file directly to XPath,
not the YANG file.

The actual usage of must/when is going to
be almost entirely related to the local module.
Adding prefixes everywhere for the local module is just
one of the many things a YANG-aware tool can be expected to do
to make it easier on the humans using YANG.

Since YANG is going to use 'current()' from XPath 2.0,
why not use default namespace as well?  Or does this annoy
the standards purists even more?  Are we suppose force
humans to enter exactly XPath 1.0 or exactly XPath 2.0,
but not something in between?  You cannot feed 'current()'
to a 1.0 XPath parser. (You could feed it '$this' however.)
Isn't 'current' also a problem, if no prefixes is a problem?

We care about conformance to YANG 1.0, and not so much
about complete implementation of XPath 2.0.  Can we can require
complete implementation of XPath 1.0, plus 'extras'?

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 18 Aug 2008 21:08:51 -0400

>Isn't 'current' also a problem, if no prefixes is a problem?

current() is lifted from XSLT, not XPath 2.0.  It's the current
node being inspected, as opposed to the context node where XPath
predicates are evaluated.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 19 Aug 2008 14:44:09 +0200 (CEST)

Phil Shafer <[email-masked]> wrote:
> current() is lifted from XSLT, not XPath 2.0.

And note that XPath 1.0 allows new functions to be defined.  It is not
a deviation from the standard to add new functions.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Aug 2008 20:13:16 +0200

> to insert the module prefix when it is missing.

Well, if XPath is used in a grouping, which is the right
prefix/namespace?
 
> You are going to feed the DSDL file directly to XPath,

I agree that it can be hacked somehow but my point is that if YANG
declares that it uses XPath 1.0 (or 2.0 or whatever) it should by all
means do it in a compliant way. Doing arbitrary YANG-specific changes to
the standards can confuse both humans and tools.

> Since YANG is going to use 'current()' from XPath 2.0,

No, as Phil pointed out, currect() comes from XSLT and is also used in
the same way in Schematron. Anybody who is reasonably XML-literate will
understand this function without any need to look in YANG spec.
 
> the standards purists even more?  Are we suppose force

I am not a standard purist, I just think W3C standards and approaches
deserve the same respect as the IETF ones, otherwise the whole thing of
using XML in NETCONF makes little sense.

> Isn't 'current' also a problem, if no prefixes is a problem?

My preference is to stay with XPath 1.0 + current() function.

> complete implementation of XPath 1.0, plus 'extras'?

I understand YANG already essentially requires it (with '$this' instead
of 'current()').

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Tue, 19 Aug 2008 14:37:39 -0400

>the standards can confuse both humans and tools.

I firmly believe that we have this.  We are using XPath in
a manner that is consistent with the XPath.  We define the
context in which XPath expressions are evaluated.  XSLT does
the exact same thing, in section 4 of the XSLT spec:

http://www.w3.org/TR/xslt#section-Expressions

    In XSLT, an outermost expression (i.e. an expression that is
    not part of another expression) gets its context as follows:
    
    * the context node comes from the current node

    * the context position comes from the position of the current
      node in the current node list; the first position is 1

    * the context size comes from the size of the current node list

    * the variable bindings are the bindings in scope on the element
      which has the attribute in which the expression occurs (see [11
      Variables and Parameters])

    * the set of namespace declarations are those in scope on the
      element which has the attribute in which the expression occurs;
      this includes the implicit declaration of the prefix xml required
      by the the XML Namespaces Recommendation [XML Names]; the default
      namespace (as declared by xmlns) is not part of this set

    * the function library consists of the core function library
      together with the additional functions defined in [12 Additional
      Functions] and extension functions as described in [14 Extensions];
      it is an error for an expression to include a call to any other
      function

The YANG draft will similarly dictate the context in which our XPath
expressions are evaluated.

(Note the except for the default namespace, which explains why this
doesn't work the way I thought it did.)

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Aug 2008 11:50:53 -0700

> Well, if XPath is used in a grouping, which is the right

(This issue is unrelated to belongs-to and the local prefix.)

You cannot resolve must/when expressions within a grouping.
The DM writer must be aware that the expression needs to
be valid anywhere a uses-stmt is valid, and the XPath is evaluated
in the context of the 'uses' module.  All the data typing
and syntax for a grouping is evaluated in the module
with the grouping, which is confusing.

Not only do you need to translate missing prefixes in must/when
to the prefix for the current module, you need to account
for different prefixes in the 'grouping' and 'uses' modules.

(sorry for the bogus example)

module A {

   prefix A;

   import IF-MIB { prefix if; }

   grouping A {
     leaf foo {
        type string;
        must "/if:ifNumber==2";
     }
     leaf bar {
        type string;
        must "../A:foo != 'fred'";
     }
     leaf baz {
        type string;
        must "../bar == 'barney'";
   }
}

module B {

   prefix B;

   import A { prefix a; }
   import IF-MIB { prefix itf; }

   container B {
     uses a:A;
   }
}

See what I mean?
(See how easy YANG is to resolve in your head? :-)
The must expressions need to be handled internally somehow,
so that the correct module is referenced, no matter what.

  prefix mapping
  --------------
  none:  A --> B
     A:  a
    if:  itf

> My preference is to stay with XPath 1.0 + current() function.

OK, I agree -- but I do not think it is a big deal in comparison
to all the other work a compiler has to do.

What really matters is the style that XPath users
will be most likely to use.  (I do not know.)
If a programmer knows that NETCONF/YANG requires XML namespaces
everywhere, and also knows that XPath 1.0 requires prefixes
in this case, then they will be inclined to use prefixes everywhere.

So you are right, by virtue of the Least Astonishment Principle.
IMO, XPath is hard to read with or without prefixes.
Either you know it or you don't.  Removing the prefixes
for the local module doesn't really help people who don't
know XPath, and it confuses people who do know it.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 20 Aug 2008 20:10:36 +0200

>     not part of another expression) gets its context as follows:

This is all true, but not relevant to the usage of NS prefixes in XPath
expressions. In XSLT, whenever you use XPath expressions containing
QNames that belong to a non-null namespace, you have to write all of
them with an *explicit* NS prefix since no prefix always means null
namespace.

Take as an example this trivial XML document:

<?xml version="1.0" encoding="utf-8"?>
<foo xmlns="http://example.com"/>

The following XSLT stylesheet (where the 'http://example.com' namespace
is defined as the default namespace) will NOT find the root element
'foo':

<?xml version="1.0" standalone="yes"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns="http://example.com"
                version="1.0">
  <xsl:output method="text"/>
  <xsl:template match="/">
    <xsl:if test="foo">Found foo.
    </xsl:if>
  </xsl:template>
</xsl:stylesheet>

You always have to define an explicit prefix and use it in the XPath
expression. This works:

<?xml version="1.0" standalone="yes"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:ex="http://example.com"
                version="1.0">
  <xsl:output method="text"/>
  <xsl:template match="/">
    <xsl:if test="ex:foo">Found foo.
    </xsl:if>
  </xsl:template>
</xsl:stylesheet>

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Wed, 20 Aug 2008 14:39:04 -0400

Ladislav Lhotka writes:
>expression.

This is true because that is how the XSLT spec says the context for
XPath expressions is defined.  It explicitly says that "the default
namespace (as declared by xmlns) is not part of this set" of
namespaces in scope for the context.

For YANG, we can (MUST) write similar (but different) rules that
define the context in which our XPath expressions are evaluated.
In our rules, we define the default namespace to be that of the
current module.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 20 Aug 2008 21:32:09 +0200

> namespaces in scope for the context.

Yes, because if it were, it would violate XPath spec.

> In our rules, we define the default namespace to be that of the

I don't think XPath 1.0 allows you to do that. It's true that in the
NETCONF&NETMOD context XML vocabularies without a namespace should never
be encountered, so the confusion between no namepace and default
namespace can probably never arise, but still - XPath 1.0 spec says it
clearly: no prefix = no namespace.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 Aug 2008 21:41:00 +0200 (CEST)

> define the context in which our XPath expressions are evaluated.

And we already have some of these in place.

> In our rules, we define the default namespace to be that of the

No, that will not work, since there is no concept of "default
namespace" in XPath 1.0.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 20 Aug 2008 21:49:25 +0200

> in the context of the 'uses' module.  All the data typing

Right, but it means that e.g., translating the module containing the
grouping to DSDL (the must-stmt to Schematron assert) is not possible
since the namespace cannot be resolved.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Aug 2008 13:14:23 -0700

> since the namespace cannot be resolved.

yes it can.
When you conceptually replace the uses node with the
contents of the grouping, you know the uses module,
the grouping module, and the import prefix maps for both.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 20 Aug 2008 17:31:52 -0400

Ladislav Lhotka writes:
>XPath 1.0 spec says it

XPath says "if the QName does not have a prefix, then the namespace
URI is null", but YANG says "if the namespace URI is null, it refers
to the current module".   I don't think this is a problem.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 20 Aug 2008 17:28:44 -0400

>No, that will not work, since there is no concept of "default

My bad.  I meant "null", not "default".  We define the null namespace
to be that of the current module.

Thanks,
 Phil

---

From: David Partain <[email-masked]>
Date: Thu, 21 Aug 2008 15:01:09 +0200

Hi,

I'm very confused about the topic at hand...

What is the last half of the 'belongs-to' thread talking about?  

- Whether we're XPath 1.0 compliant or not?  (most, maybe all, people seem to 
think we are)
- Whether we have to have a prefix or not on a 'must' statement?
- Something else?

As Andy correctly points out, we're certainly not talking about whether to add 
a prefix to belongs-to or not anymore.

Looks to me like we have an answer to #1.

What are opinions / proposed resolutions about #2?

Cheers,

David

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Aug 2008 15:51:57 +0200 (CEST)

> - Whether we have to have a prefix or not on a 'must' statement?

The question is if we are compliant to XPath 1.0 when we say:

  Elements without a namespace refer to nodes in the current module.

(note: this is the text from draft -02).

I think we are, since XPath 1.0 allows both prefixed and unprefixed
elements, which refer to elements with and without a namespace,
respectively.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Aug 2008 16:33:53 +0200

Hello,
The draft says in chapter 6.3.1. Language Extensions

"When an imported extension is used, the keyword must be qualified using the prefix with which 
the extension's module was imported."

The text above seems to imply that only imported extensions need a prefix. Please remove the 
word imported.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Aug 2008 16:38:55 +0200

Hello,
I WANT to forbid using different prefixes in the module and it's submodules.  I see no 
advantage, but find the idea rather confusing.

If the prefix in belong-to is optional I don't really see the advantage, you must still be 
capable of handling non-prefixed submodules. Or would it be mandatory?

otherwise I don't see the strong need for the prefix in belongs-to, but can live with it.
Balazs

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Aug 2008 08:18:46 -0700

Balazs Lengyel wrote:
> "When an imported extension is used, the keyword must be qualified using 
> the prefix with which the extension's module was imported."
> 
> The text above seems to imply that only imported extensions need a 
> prefix. Please remove the word imported.
> 

I think you are right.

If I want to define my own 'foo:leaf' clause, then of course
I have to use foo:leaf, even in the foo module.
If I just use 'leaf' in the foo module, then
the YANG keyword wins, and 'foo:leaf' will not be checked.
This would not be the case if the extension name
did not conflict. (foo:my-leaf <--> my-leaf no problem).

For consistency, an extension should always be used with a prefix.
But I don't know if a special CLR is needed.  The same issues
apply to any imported symbol.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Aug 2008 17:49:23 +0200

> - Whether we're XPath 1.0 compliant or not?  (most, maybe all, people seem to 

YANG draft defines the null namespace to be the namespace of the current
module, which is IMO not acceptable - null namespace has a very precise
meaning similar to empty set in the set theory.
 
> - Whether we have to have a prefix or not on a 'must' statement?

I believe the answer is yes - actually, a namespace prefix has to be
attached to every QName (component) of the XPath 1.0 expression that is
in the argument of must-stmt.

> - Something else?

$this -> current(), but there seems to be consensus on this.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Thu, 21 Aug 2008 12:20:10 -0400

>meaning similar to empty set in the set theory.

Could you please point me a precise definition?

>in the argument of must-stmt.

This will our XPath expressions much uglier and much more error
prone.

I do not see any evil in allowing YANG to define the meaning of the
null namespace as part of the context in which XPath expressions
are evaluated.  I do not see this as a source of confusion for data
modelers and see the alternative as problematic.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Aug 2008 19:24:22 +0200

> modelers and see the alternative as problematic.

I do not see how requiring prefixes can lead to confusion. We optimize
for the readers and a prefix is makes things unambiguous and avoids
surprises if people cut'n'paste XPATH expressions.

The only downside seems to be that expressions get slightly more
verbose. To what extend is this really a problem? Do we have any idea
how many local qnames our XPATH expressions will contain? Anything we
can learn here from proprietary data modeling languages?

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Aug 2008 10:46:32 -0700

> can learn here from proprietary data modeling languages?

Well for starters, you really do not want prefixes when
writing must statements for siblings within a grouping.
You really mean 'use the local namespace' when you leave
the prefix out in this case.

However, as I pointed out in a previous mail, the tools
will need to examine all the prefixes in the context of
the grouping module, and translate them to the uses module.
Whether the prefix is present or not has no impact whatsoever
on the complexity of the code.

If we go back to first principles for a moment, the reason
prefixes are optional is to let the DM designer decide.
It seems like forcing a usage either way moves against
this valid design principle.

Consistent handling of QNames throughout the YANG module
would be less confusing than doing otherwise.  That much
I am certain of -- the rest, not so much...

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 21 Aug 2008 14:50:00 -0400

>surprises if people cut'n'paste XPATH expressions.

True but is also means I can't say:

    leaf one { ... }
    leaf two { ... }
    leaf three {
        must "../one || ../two" { ... }
    }

I must use the prefix, even thru I just defined them without
a prefix.

(Sure, this is similar to types, which are defined with no
prefix but must have one when used, but it sure feels worse.)

>can learn here from proprietary data modeling languages?

Real world examples appended.  The ugly ones get uglier, but
they are already ugly enough that it may not matter.

Thanks,
 Phil

example one:

            must not(../../../../snmp/routing-instance-access/access-list/default)

becomes:

            must not(../../../../snmp:snmp/snmp:routing-instance-access/snmp:access-list/snmp:default)

example two:

        leaf interface-name {
            type junos:interface-unit;
            must ../../../../protocols/pim/interface[name = current()]/disable
                 || ../../../../routing-options/multicast/interface[name = current()]/disable
                 || ../../../../routing-options/multicast/interface[name = current()]/maximum-bandwidth
                 || not(../../../../protocols/pim/interface[name = current()]
                        || (../../../../protocols/pim/interface[name = 'all']
                            && not(../../../../protocols/pim/interface[name = 'all']/disable))))
            {
		error-message "PIM and multicast cannot be enabled on the same interface in the [edit routing-options] hierarchy";
            }
        }

becomes:

        leaf interface-name {
            type junos:interface-unit;
            must ../../../../protocols/pim:pim/pim:interface[pim:name = current()]/pim:disable
                 || ../../../../routing-options/pim:multicast/pim:interface[pim:name = current()]/pim:disable
                 || ../../../../routing-options/pim:multicast/pim:interface[pim:name = current()]/pim:maximum-bandwidth
                 || not(../../../../protocols/pim:pim/pim:interface[pim:name = current()]
                        || (../../../../protocols/pim:pim/pim:interface[pim:name = 'all']
                            && not(../../../../protocols/pim:pim/pim:interface[pim:name = 'all']/pim:disable))))
            {
		error-message "PIM and multicast cannot be enabled on the same interface in the [edit routing-options] hierarchy";
            }
        }
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Aug 2008 21:52:33 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> > "When an imported extension is used, the keyword must be qualified using the prefix with which the extension's module was imported."
> > The text above seems to imply that only imported extensions need a prefix. Please remove the word imported.
> > 
> 
> I think you are right.
> 

Actually, there are two issues here,  The general rule is defined in
4.2.1 and says:

  References to definitions in the local module MAY use
  the prefix notation.

But this doesn't currently apply to extensions, since they must have a
prefix.  There are two reasons for this: one is to keep the grammar
simpler.  An unprefixed keyword is always a YANG keyword.  The other
reason is to keep the YIN mapping simpler.  In YIN, the extension MUST
be namespace qualified, since the XML namespace for the extension is
different than the namespace for the YANG keywords.

We have two options:

 1) allow local extensions to be used w/o a local prefix, and change
    the text in 6.3.1 to:

      When an imported extension is used, the extension's keyword must
      be qualified using the prefix with which the extension's module
      was imported.  If an extension is used in the module where it is
      defined, the extension's keyword MAY be qualified with the
      module's prefix.

    or simply remove the text about prefixes in 6.3.1, and just keep
    the the general rule in 4.2.1

    We must also change the YIN mapping rules so that a prefix is
    added in the YIN output, if needed.

 2) keep the rule that extensions must have prefix, and change the
    text in 4,2.1 to:

      References to definitions in the local module MAY use
      the prefix notation, except for references to language
      extensions, which MUST use the prefix notation.
  
   and also change the text in 6.3.1 to:

      When an imported extension is used, the extension's keyword must
      be qualified using the prefix with which the extension's module
      was imported.  If an extension is used in the module where it is
      defined, the extension's keyword MUST be qualified with the
      module's prefix.

My personal preference is 2.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Aug 2008 22:01:08 +0200 (CEST)

> prefix but must have one when used, but it sure feels worse.)

No, when you refer to a local type or grouping, you can omit the
prefix.

> >how many local qnames our XPATH expressions will contain?

I suspect most must expressions will NOT refer to external identifiers.  

/martin

---

From: David Partain <[email-masked]>
Date: Fri, 22 Aug 2008 13:55:57 +0200

On Thursday 21 August 2008 21.52.33 Martin Bjorklund wrote:
> > > "When an imported extension is used, the keyword must be qualified
> > > using the prefix with which the extension's module was imported." The
> > > text above seems to imply that only imported extensions need a prefix.
> > > Please remove the word imported.
> >
> > I think you are right.
> >

Seems good to me.

David

---

From: Phil Shafer <[email-masked]>
Date: Fri, 22 Aug 2008 08:46:49 -0400

>different than the namespace for the YANG keywords.

Don't these reasons apply equally to types:

    module foo {
        type int32 { ... }
        leaf f { type int32; }
    }

Is "f" foo:int32 or the real YANG int32?

> 1) allow local extensions to be used w/o a local prefix, and change

This would be disturbing to the reader.  Non-builtins that
can appear where builtins appear should be easy for the
reader to distinquish and not ambiguous.

>      defined, the extension's keyword MUST be qualified with the

Sounds good, but we should add types to this also.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Aug 2008 15:26:20 +0200

> Is "f" foo:int32 or the real YANG int32?

The set of builtin types is small and likely to stay stable and that
is why we decided the last time we discussed this (before there was a
WG) that it is OK to not require prefixes on types. This does not mean
we have to reach the same conclusion this time of course. ;-)

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Aug 2008 15:51:36 +0200

> different than the namespace for the YANG keywords.

But I think the main reason is that YANG/YIN keywords are in the
"urn:ietf:params:xml:ns:yang:1" or "urn:ietf:params:xml:ns:yang:yin:1"
namespace whereas the extension keyword is in the namespace of the
module that defines it.

So IMO it is proper to require the extension keywords to always carry
the prefix.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: David Partain <[email-masked]>
Date: Fri, 22 Aug 2008 16:00:04 +0200

Hi,

Contributor hat.

I think we should reach the same conclusion... the less clutter, the better.

David

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 22 Aug 2008 19:37:51 +0200

Hello,
+1
I don't want mandatory prefixes for  local defined types. We sad readability is the big bonus 
for YANG, so cluttering all the stuff with prefixes would be ugly.

Extensions are a rarer sort of animal, so asking for prefixing there is not that bad. I agree 
with martin we should keep it (although we could live with optional prefixing as well.)

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: "tom.petch" <[email-masked]>
Date: Wed, 27 Aug 2008 18:17:47 +0200

---- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "David Partain" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 21, 2008 5:49 PM
Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re:belongs-to)

> meaning similar to empty set in the set theory.

I think that Lada is spot on with this, and has been throughout this thread and
its precursors.  Null namespace is a different concept.  For YANG to redefine
its meaning will confuse anyone familiar with XPath 1.0.

(I first saw the light after reading
http://www.rpbourret.com/xml/NamespacesFAQ.htm
)

Tom Petch

---

From: Phil Shafer <[email-masked]>
Date: Wed, 27 Aug 2008 15:56:44 -0400

"tom.petch" writes:
>Null namespace is a different concept.  For YANG to redefine

I'm surprised that this is considered confusing.  In a YANG XPath,
the null namespace (elements with no namespace URI) refers to the
current module.  This is simple and natural.  Adding prefixes at
inconsistent moments is sure to be far more confusing.

Compare this is XSD, where the null namespace refers to the namespace
named in the targetNamespace attribute on the <xsd:schema> element.
Or XQuery, where unprefixed elements are in the default element/type
namespace, which can be set in a number of ways.  Or many other w3c
standards that define the context in which XPath expressions are
evaluated.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Aug 2008 14:01:46 -0700

> standards that define the context in which XPath expressions are

I know I have not helped this discussion,
but I agree with Phil and Lada.  (does not compute!)

There has been an ongoing debate which (at its core)
is really over the validity of YANG as an abstraction,
as opposed to a view that the model is really the
external XML instance document for the <config> element.

I strongly agree with Phil that the YANG file represents
the YANG abstraction, and its constructs do not have to directly
represent XML instance documents.  We should just stuck
with XSD if we are interested in modeling XML documents
instead of network device configuration databases.

It seems reasonable to require must-stmt conversion
for YANG to DSDL tools, so there are no missing prefixes at all.
Namespace declarations must be present for every prefix used.
This would preserve the YANG abstraction and provide
the expected XPath 1.0 syntax in the output files.

> _______

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 Aug 2008 13:01:09 +0200

> the null namespace (elements with no namespace URI) refers to the

I think you are mixing prefixes with namespaces here.

> named in the targetNamespace attribute on the <xsd:schema> element.

No. It just says that elements names with no *prefix* belong to a
certain XML namespace. RELAX NG and Schematron do the same. The point is
they use just element names, not XPath expressions. YANG does it
actually too - if you say "container foo", no prefix is needed and
that's OK. But XPath 1.0 has this rule that no prefix means null
namepace, full stop. If XSD used XPath 1.0 anywhere, be sure they would
use explicit prefixes. 
 
> standards that define the context in which XPath expressions are

I am not aware of any single one that uses XPath 1.0 in this way.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 Aug 2008 13:11:21 +0200

> instead of network device configuration databases.

If YANG spec says that the must argument is an XPath 1.0 expression and
then examples are shown that use the "local" namespace, I can guarantee
you that it will raise quite a few eyebrows. I don't know how much this
simplification would really help readers or authors of YANG modules, but
it can easily give an impression that YANG is a sloppy standard.

YANG combines two technologies with some history and their own
idiosycrasies, so I think it's crucial to be quite conservative and keep
all standards, since otherwise the other camp may dismiss the whole
thing straight away.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Thu, 28 Aug 2008 18:25:12 +0200

----- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Ladislav Lhotka" <[email-masked]>; "David Partain"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, August 27, 2008 9:56 PM
Subject: Re: [netmod] XPath compliance and prefix on 'must'? (was Re:belongs-to)

> inconsistent moments is sure to be far more confusing.

The null namespace (or no namespace) is a namespace.  To redefine that namespace
to be something different is likely to, as Lada suggests, diminish the standing
of YANG in the eyes of those familiar with XPath(/XML/XSD...).

Tom Petch