Jernej Tuljak <jern...@mg-soft.si> wrote:
> Ladislav Lhotka je 11.12.2015 ob 9:55 napisal:
> >> On 11 Dec 2015, at 09:23, Martin Bjorklund <m...@tail-f.com> wrote:
> >>
> >> William Lupton <wlup...@broadband-forum.org> 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

Reply via email to