Subject: Re: [netmod] XML encoding rules for built-in types

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

Greetings,

The thread "XPath expressions in must" (which starts at 
http://www.ietf.org/mail-archive/web/netmod/current/msg00624.html) included 
at least two issues.

To me, one seems to have been resolved by replacing $this with current().  See 
http://www.ietf.org/mail-archive/web/netmod/current/msg00747.html

The second was the claim that 'must' expressions will always have to have a 
namespace prefix in order to be compliant with XPath 1.0 and that YANG is 
therefore not compliant.  My personal take on rough consensus is that it 
seems to be that YANG _does_ use an unmodified XPath 1.0.  However, we have 
one remaining issue that I don't see resolved:

Lada wrote:
> The YANG draft says:
>
> "The null namespace is defined to be the namespace of the current
> module".
>
> I understand this was an attempt to avoid the XPath requirement to write
> explicit namespace prefixes but IMO it is not acceptable. It is the same
> like defining empty set to contain something. Null namespace means NO
> namespace.

Martin suggested that the specification say "Elements without a namespace
refer to nodes in the current module" and received very few comments on that 
suggestion (Phil liked it).

So, the chairs request that the WG respond whether this change addresses the 
concerns Lada brought up or not.

If you believe it does _NOT_ address the concerns, please suggest an alternate 
change that would.

Cheers,

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Aug 2008 13:40:45 +0200

> suggestion (Phil liked it).

Clarification: I think this implies that YANG translators have to
transform expressions by adding the correct prefixes since outside the
YANG context, prefixes are required. (Correct me if I am wrong.)

/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: Fri, 22 Aug 2008 14:16:12 +0200

> YANG context, prefixes are required. (Correct me if I am wrong.)

That would be a necessary workaround and the translator would also have
to parse the expressions. However, I think it's also a problem for YANG
itself to call something XPath 1.0 if the semantics of the expressions
is different from what the XPath 1.0 spec says.

Perhaps we should look at XPath 2.0 after all.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

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

>YANG context, prefixes are required. (Correct me if I am wrong.)

Yes, tools would need to rewrite XPath expressions to add prefixes.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 23 Aug 2008 11:04:53 +0200 (CEST)

> YANG context, prefixes are required. (Correct me if I am wrong.)

Note that YANG does not reqiure an implementaton of XPath at all.  An
implementation is free to code the restrictions by hand.

But if you have a proper XPath implementation, yes, then you will have
to translate prefixes.  You can never just use all must expressions as
they are written in the modules, since all prefixes are local to each
module, so you might have the prefix 'foo' map to different XML
namespaces in different modules:

  module a { 
     prefix foo;
    
     leaf y { type int32; }
     must "/foo:x == 42";
  }

  module b { 
     prefix foo;

     leaf y { type int32; }
     must "/foo:y == 4668";
  }

If you have your data as an XML instance document, you will also have
to add whaterver root node you have in your XML instance document.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 23 Aug 2008 06:25:08 -0700

> implementation is free to code the restrictions by hand.

But a YANG to YIN or YANG to DSDL translator does need to
deal with prefix conversion.  Clearly the 'no prefix==local module'
rule only applies within a YANG file, not YIN, not XML or any kind.

> ____

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 24 Aug 2008 10:43:20 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> >>> refer to nodes in the current module" and received very few comments on that suggestion (Phil liked it).

As long as we're talking about must expressions, I do not agree.  The
rule that "Elements without a namespace refer to nodes in the current
module" (from -01) for must expressions applies to YIN as well.

For DSDL, you may be right.  But I don't think we have agreed exactly
what the DSDL mapping will be used for, or how.  That's another
discussion though.

/martin

---

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

> module" (from -01) for must expressions applies to YIN as well.

What is the rationale for this decision?
It seems to me the YIN version should be straight XML,
ready to input to XML tools that do not know about YANG modules.

> what the DSDL mapping will be used for, or how.  That's another

It is the implementation choice that the IESG decided it likes best.
When implementing NETCONF, whether you process YANG files directly,
or process DSDL files directly, or some combination,
or something else entirely -- has no impact whatsoever
on your RFC 4741 conformance.

Andy

---

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

> ready to input to XML tools that do not know about YANG modules.

Maybe we're talking about different things.  Standard XML tools that
do not know about YANG modules does not know how to interpret the must
expression, so for them it's just a string.  I'm saying that if the
YANG statement is:

   must "foo:a = current()";

then the YIN statement is:

   <must condition="foo:a = current()"/>

No prefix translation in the YIN translation.

/martin