Subject: Re: [netmod] derived-from() and derived-from-or-self() arguments

From: William Lupton <[email-masked]>
Date: Thu, 10 Dec 2015 15:53:51 +0000

Martin,

Thanks for the reply and sorry for my delay in following up. Maybe I'm misunderstanding your point, but surely any node-set argument can be a prefixed string, e.g I found this example in a NETMOD "Y26 again, sorry" thread.

  augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
    when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
       + "'TLSA')";

Arguably YANG authors might find it more natural always to use prefixed strings such as 'iana-dns-parameters:TLSA' when referring to a namespace-qualified entity?

William

PS, The current definitions perhaps need to be tightened up wrt module-name (MUST be valid prefix) and identity-name (MUST NOT be qualified)?

> On 16 Nov 2015, at 19:51, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 
> William Lupton <[email-masked]> wrote:
>> Hi,
>> 
>> I'm sure there's an obvious reason for this, but could someone explain why
>> these functions need a separate module-name argument rather than just using
>> that module's prefix on the identity-name argument?
> 
> The only reason is that there are no existing functions that take a
> prefixed string as an argument.  I think it would be possible to
> change these functions to take just two arguments, but I am not sure
> it is worth it?
> 
> /martin
> 
>> For example, I saw derived-from(x, "ex-module", "foo") in a recent message
>> but (assuming that "ex" is the prefix for "ex-module") will this always be
>> the same as derived-from(x, "ex:foo")?
>> 
>> Thanks,
>> William

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Dec 2015 09:23:07 +0100 (CET)

William Lupton <[email-masked]> wrote:
> Martin,
> 
> Thanks for the reply and sorry for my delay in following up. Maybe I'm
> misunderstanding your point, but surely any node-set argument can be a
> prefixed string, e.g I found this example in a NETMOD "Y26 again,
> sorry" thread.
> 

But in this example there is no prefixed *string value* - the prefix
is used in a LocationPath, not a string.

> Arguably YANG authors might find it more natural always to use
> prefixed strings such as 'iana-dns-parameters:TLSA' when referring to
> a namespace-qualified entity?

Maybe, yes.  It would be useful to hear others opinions!

/martin

> William
> 
> PS, The current definitions perhaps need to be tightened up wrt
> module-name (MUST be valid prefix) and identity-name (MUST NOT be
> qualified)?
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Dec 2015 09:55:19 +0100

> On 11 Dec 2015, at 09:23, Martin Bjorklund <[email-masked]> wrote:
> 

Right, an identity isn't a node-set.

> Maybe, yes.  It would be useful to hear others opinions!

A code that evaluating these functions needs to know a lot about the underlying YANG data model anyway, so I think it is no problem to resolve arbitrary QNames. I am thus in favour of William's proposal.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Jernej Tuljak <[email-masked]>
Date: Fri, 11 Dec 2015 10:50:32 +0100

> A code that evaluating these functions needs to know a lot about the underlying YANG data model anyway, so I think it is no problem to resolve arbitrary QNames. I am thus in favour of William's pro…

If there are no existing functions that take a prefixed string literal, 
why not simply replace the module name argument with a prefix string? I 
don't see why a module name needs to be used here at all either - in 
fact, it seems to be promoting the idea of breaking out of module 
containment using XPath instead of discouraging it - you should not be 
able to refer to an identity if it is not defined within an imported or 
the enclosing module.

Jernej

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Dec 2015 12:22:41 +0100 (CET)

Jernej Tuljak <[email-masked]> wrote:
> > A code that evaluating these functions needs to know a lot about the
> > underlying YANG data model anyway, so I think it is no problem to
> > resolve arbitrary QNames. I am thus in favour of William's proposal.
> 
> If there are no existing functions that take a prefixed string
> literal, why not simply replace the module name argument with a prefix
> string? I don't see why a module name needs to be used here at all
> either - in fact, it seems to be promoting the idea of breaking out of
> module containment using XPath instead of discouraging it - you should
> not be able to refer to an identity if it is not defined within an
> imported or the enclosing module.

If we're going to use the prefix, I prefer to use a single QName.  I
agree with your comment as well.  So unless anyone objects, I will
make this change.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Dec 2015 12:23:39 +0100

> On 11 Dec 2015, at 12:22, Martin Bjorklund <[email-masked]> wrote:
> 

+1

Lada

---

From: William Lupton <[email-masked]>
Date: Fri, 11 Dec 2015 11:24:42 +0000

Thanks all.

> On 11 Dec 2015, at 09:50, Jernej Tuljak <[email-masked]> wrote:
> 

I like the idea of just thinking of it as a QName. This also suggests a general principle that any future functions that needed to refer to types, identities etc would use QNames?

> If there are no existing functions that take a prefixed string literal, why not simply replace the module name argument with a prefix string? I don't see why a module name needs to be used here at all either - in fact, it seems to be promoting the idea of breaking out of module containment using XPath instead of discouraging it - you should not be able to refer to an identity if it is not defined within an imported or the enclosing module.

I assume that "module name" always meant "prefix" because otherwise how would one deal with namespaces and revisions? Using a QName clarifies that it's a prefix.

William