Re: [netmod] derived-from() and derived-from-or-self() arguments
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
> 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
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. /martin ___ 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 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
> 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 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
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
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