Ladislav Lhotka je 11.12.2015 ob 9:55 napisal:
On 11 Dec 2015, at 09:23, Martin Bjorklund <[email protected]> wrote:

William Lupton <[email protected]> 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 <[email protected]> wrote:

Hi,

William Lupton <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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


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

Reply via email to