Subject: [netmod] identityref

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Dec 2008 11:17:23 -0800

Hi,

sec. 9.10.3 has an editors note: how to handle prefixes?

IMO, we just follow the XML 'expanded name' example,
and declare that the canonical form for an identityref
value within an XML instance document does not have a fixed prefix.
It must be evaluated according to XML.

(We do not officially care about representations other than XML.)

It should be more clear in 9.10.3 that the prefix
in the QName content is an XML prefix associated with
the XML Namespace (which has the same value as the
module 'namespace-stmt').  It is NOT the module prefix.

There is no module name or namespace-stmt in the example in 9.10.4,
so the reader really has no clue that is where the particular
xmlns value came from.

The prefix is for the namespace URI of the module
that contains the 'des3' identity, which may be different than
the namespace for the 'crypto' leaf itself.

(That's obvious in the example to people who really know XML,
but stating in text might help as well.)

Andy

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 09 Dec 2008 09:58:30 -0800

> but stating in text might help as well.)

Some more details for the identityref section on
the not so obvious 'default-stmt' for an identityref
leaf or leaf-list:

module foo {

      namespace "foo-ns";
      prefix foo;

      import "crypto-base" {
          prefix "crypto";
      }
      import des { prefix des; }

      identity my-des3 {
         base "des:des3";
      }

      leaf crypto {
          type identityref {
              base "crypto:crypto-alg";
          }
          default "des:des";
      }

      leaf crypto2 {
          type identityref {
              base "crypto:crypto-alg";
          }
          default "my-des3";
      }
}

In a YANG module, the identityref prefix is a module prefix,
not an XML prefix. (No prefix means the local module.)

I really like the extensibility and distributed tree design
of the identityref. (Thanks Juergen!)

The only problem is that the canonical form depends on
the context in which it appears.  Text config files
are out of scope, which is good. Since module prefixes
are not required to be unique, yet another format
might be needed for that.

Only CLR: the canonical form(s) MUST have a prefix.

Andy