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

[Jernej Tuljak]

Ladislav Lhotka je 11.12.2015 ob 9:55 napisal:

On 11 Dec 2015, at 09:23, Martin Bjorklund  wrote:

William Lupton  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.

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

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

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


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!

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.


Jernej



Lada



/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)?


On 16 Nov 2015, at 19:51, Martin Bjorklund  wrote:

Hi,

William Lupton  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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[William Lupton]

Thanks all.

> On 11 Dec 2015, at 09:50, Jernej Tuljak  wrote:
> 
> Ladislav Lhotka je 11.12.2015 ob 9:55 napisal:
>> 
>> 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.

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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

> On 11 Dec 2015, at 12:22, Martin Bjorklund  wrote:
> 
> Jernej Tuljak  wrote:
>> Ladislav Lhotka je 11.12.2015 ob 9:55 napisal:
 On 11 Dec 2015, at 09:23, Martin Bjorklund  wrote:
 
 William Lupton  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.
> 
>  augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
>when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
>   + "'TLSA')";
 But in this example there is no prefixed *string value* - the prefix
 is used in a LocationPath, not a string.
>>> Right, an identity isn't a node-set.
>>> 
> 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!
>>> 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.

+1

Lada

> 
> 
> /martin

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




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

William Lupton  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.
> 
>   augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
>+ "'TLSA')";

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)?
> 
> > On 16 Nov 2015, at 19:51, Martin Bjorklund  wrote:
> > 
> > Hi,
> > 
> > William Lupton  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
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

> On 11 Dec 2015, at 09:23, Martin Bjorklund  wrote:
> 
> William Lupton  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.
>> 
>>  augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
>>when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
>>   + "'TLSA')";
> 
> But in this example there is no prefixed *string value* - the prefix
> is used in a LocationPath, not a string.

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

> 
>> 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!

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

> 
> 
> /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)?
>> 
>>> On 16 Nov 2015, at 19:51, Martin Bjorklund  wrote:
>>> 
>>> Hi,
>>> 
>>> William Lupton  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
>> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[William Lupton]

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  wrote:
> 
> Hi,
> 
> William Lupton  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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

Hi,

William Lupton  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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[William Lupton]

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?

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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod