Subject: [netmod] use of prefix with local names

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 04 Jun 2008 11:24:21 +0200

Hi,

draft-ietf-netmod-yang-00 says:
"References to definitions in the local module MAY use the prefix
notation."

The use of local prefix can be seen e.g., in inet-types.yang: 

    typedef ip-address {
        type union {
            type inet:ipv4-address;
            type inet:ipv6-address;
        }
        ...
    }

    typedef ipv4-address {
       ...
    }

Equivalently, "type ipv[46]-address;" could be used, without the local
prefix.

I think this dichotomy is confusing and inconsistent since

1. The typedef'ed name cannot have the prefix.

2. When referencing names from external modules, one can only get to
top-level definitions whereas with the local prefix names in all scopes
can be referenced.

My suggestion is to remove the possibility of using the local prefix
entirely (does it help anything?), or at least allow it only for
referencing top-level definitions in the local module.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 04 Jun 2008 07:30:16 -0700

> 1. The typedef'ed name cannot have the prefix.

The prefix is not used in any definitions in this manner.
Why is this a problem?

> top-level definitions whereas with the local prefix names in all scopes

This has nothing to do with prefixes.
Only the top level identifiers are exported.
The nodes /A/foo and /B/foo are not the same, and 'foo'
is not required to be unique (outside its sibling set).
You cannot export 'foo' on its own, prefix or not.

Within a module, only the local typedefs and groupings
within the direct ancestor nodes are visible.  This is
extended to the ancestors of the grouping, if the current
node is a 'uses-stmt'.  It is not 'all scopes'.

You cannot override a typedef or grouping name in this 'definition path',
but the same name can be used for multiple definitions
in different paths. (Just like C and just as simple to implement :-)

> referencing top-level definitions in the local module.

Phil had a suggestion previously to always use the local prefix.
Now you are suggesting to never use the local prefix.  I don't
really care that much.  It is half a line of code to make sure
the prefix given is not the local prefix (except inside submodules ;-).
The current solution is fine with me.

BTW, I prefer the 'SMIv2 way' of listing all imported identifiers
in the imports section, and never use prefixes ever.
There are different techniques to achieve the same 'future-proofing'
that the prefix provides, and it is subjective which technique
one might prefer.

> Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 04 Jun 2008 20:54:39 +0200

> The prefix is not used in any definitions in this manner.

Since the definition and its reference use different names.

> You cannot export 'foo' on its own, prefix or not.

I know, but it makes the semantics of prefix-qualified references to
external symbols different from references to local ones. Imagine a
module that imports itself with a different prefix (btw. is this
allowed?).

> Phil had a suggestion previously to always use the local prefix.

Ar least this would be consistent, but I fail to see the information
value that the prefix carries since every such reference starts with a
keyword (uses of type) that signals very clearly what the next token is.
Extensions are different in this respect, so with them it makes sense to
always require prefixes.

I am not saying it's a big problem, but rather an unnecessary
complication.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2008 09:48:27 +0200

> referencing top-level definitions in the local module.

I do not get the point. I assume it takes extra code to disallow the
use of the local prefix and I don't really understand which problem is
getting fixed by not allowing local prefixes.

/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: Ladislav Lhotka <[email-masked]>
Date: Thu, 05 Jun 2008 10:10:54 +0200

> use of the local prefix and I don't really understand which problem is

It's the other way around - if the prefixes were only reserved for
referring to external definitions, the code can immediately look up the
module corresponding to the prefix and the definition in it. As it is
now, the code has to check whether the prefix is local and just ignore
it if it is the case. Not a big deal of course.

> getting fixed by not allowing local prefixes.

I will answer by another question: What problem is getting fixed by
allowing local prefixes?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2008 10:22:38 +0200

On Thu, Jun 05, 2008 at 10:10:54AM +0200, Ladislav Lhotka wrote:
 
> referring to external definitions, the code can immediately look up
> the module corresponding to the prefix and the definition in it. As
> it is now, the code has to check whether the prefix is local and
> just ignore it if it is the case. Not a big deal of course.

OK, depends on how you implement things. If I get a prefix, I lookup
the module and it does not matter whether the prefix points to the
local module or some external module.
 
> I will answer by another question: What problem is getting fixed by

Wrong question. The correct question to ask is: What problem is
getting fixed by disallowing local prefixes? ;-)

My point is that it is unambiguous what foo:bar means in the module
with prefix foo and hence I so far I see no reason to declare this
illegal.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 05 Jun 2008 11:31:09 +0200

> with prefix foo and hence I so far I see no reason to declare this

I am approaching it from the position that YANG is not yet something
established and so it is IMO useful to also ask which features can be
removed. Since I don't see any added value in using the local prefix,
it's a good candidate for removal. This is just Occam's razor.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2008 11:33:54 +0200

On Thu, Jun 05, 2008 at 11:31:09AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v ??t 05. 06. 2008 v 10:22 +0200:

For me, you are _adding_ a CLR without a sound justification for it.

If I can write foo:bar everywhere, why should I not be allowed to use
it in the module defining foo?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 05 Jun 2008 11:48:58 +0200

> For me, you are _adding_ a CLR without a sound justification for it.

Sorry, I already wanted to ask few times what CLR means. Wikipedia knows
it only as "Common Language Runtime". :-)

But if we started from a clean slate, both options - with and without
local prefixes - being functionally equivalent, the simpler one should
be preferred.

> it in the module defining foo?

I can also prepend the full namespace to each local identifier and it
would also be unambiguous. Should I be allowed to do so?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2008 11:54:21 +0200

> it only as "Common Language Runtime". :-)

Crappy Little Rule
 
> local prefixes - being functionally equivalent, the simpler one should

We will not converge...
 
> would also be unambiguous. Should I be allowed to do so?

This is a different subject. Right now, namespaces as prefixes are not
legal anywhere in YANG. But yes, if they were legal, I would expect
that they are legal everywhere, including the module that defines the
namespace. ;-)

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 05 Jun 2008 13:14:56 +0200

> that they are legal everywhere, including the module that defines the

Python has a similar mechanism for refering to foreign symbols but you
cannot prepend the path of the current module to local identifiers - and
no one has probably ever considered it as something useful.

Moreover, without mentioning the possibility of using the local prefix,
the prefix statement directly under module can be made optional,
becoming effectively just a part of module metadata.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2008 13:50:16 +0200

> becoming effectively just a part of module metadata.

Lets just agree to disagree on the first issue. On the second topic,
the design team felt that it is useful to document a "common" prefix
to be used by others when important a module. In other words, the
prefix statement exists for a very different reason.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Jun 2008 13:50:42 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> with prefix foo

Or rather, we should make sure it is unambiguous.  The current text
does not spell this out explicitly, but says:

  When a YANG implementation resolves a reference to an unprefixed
                                                        ^^^^^^^^^^
  type or grouping, it searches up the levels of hierarchy in the schema
  tree, starting at the current level, for the definition of the type or
  grouping.

I agree with Juergen that it should be possible to use the local
prefix.  Compare with XML:

  <foo xmlns="http://example.com"
       ex:xmlns="http://example.com">
    <bar/>
    <ex:bar/>
  </foo>

Both in YANG and XML you can choose to always use the local prefix, or
always use no prefix for local/default, or a combination.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 05 Jun 2008 15:53:57 +0200

>        ex:xmlns="http://example.com">
But here the mappings prefix->URI are explicitly declared, and exactly
the same mechanism is used for other namespaces. In YANG, it would
correspond to the following:

module mymodule {
  ...
  prefix foo;
  import mymodule { prefix bar; }
  ...
}

Here, the *top-level* symbols of mymodule should indeed be available as
bar:symbol.

As Juergen pointed out, the "prefix foo" statement serves a different
purpose.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C