On Fri, Jan 22, 2016 at 5:00 AM, Martin Bjorklund <m...@tail-f.com> wrote:
> Hi, > > Andy Bierman <a...@yumaworks.com> wrote: > > Hi, > > > > I am strongly against adding more features to YANG 1.1 at this time. > > Do you refer to the proprietary extension to restrict i-is? If so, I > agree (and Balazs just did in a separate email as well) that this is > out of scope. > > How would such an extension work, given that a tool MAY ignore this extension? A plain client thinks the instance-identifier can hold any valid instance, and is surprised that valid values are rejected by the server (which don't match the magic extension rules) Use XPath to further restrict the instance, so a plain client can see it. > > /martin > Andy > > > > The deadline for new features has long passed. > > > > > > Andy > > > > > > On Fri, Jan 22, 2016 at 12:27 AM, Balazs Lengyel < > > balazs.leng...@ericsson.com> wrote: > > > > > Hello, > > > I agree we don't need to change the encoding, but we need to define how > > > that encoding is visible/available when evaluating Xpath expressions. > Today > > > the draft says: > > > - instance-identifier does not have a canonical format > > > - XPath uses the canonical format > > > The two together make it impossible to use it in Xpath, even though > there > > > are people that would like to do that. > > > - Martin mentioned a proprietary extension > > > - we would like it. > > > > > > So I would propose to > > > ---- change to 9.1 > > > > > > Old: In particular, any XPath expression evaluations are done using > the canonical form. > > > > > > New: In particular, whenever a canonical form exists, any XPath > > > expression evaluations are done using the canonical form. > > > > > > --- add to 9.13.2 > > > > > > For instance-identifiers XPath expression evaluations are done using > the lexical form. > > > > > > > > > regards Balazs > > > > > > > > > On 2016-01-21 18:53, Andy Bierman wrote: > > > > > > Hi, > > > > > > There is no need to change the XML encoding or YANG encoding > > > of an instance-identifier. The prefixes are completely different > > > in each. Prefixes clashes do happen, especially since > > > there is no expectation that they are unique. They are short strings > > > with no naming conventions at all. E.g., I have seen "if" for > > > interfaces in multiple modules. > > > > > > Andy > > > > > > > > > On Thu, Jan 21, 2016 at 8:51 AM, Balazs Lengyel < > > > <balazs.leng...@ericsson.com>balazs.leng...@ericsson.com> wrote: > > > > > >> Hello Martin, > > >> If the RFC would define that in XPath expressions an instance > identifier > > >> MUST be evaluated to a string that complies to the lexical format, > using > > >> the rematch function, we could do everything we need. In real life > prefix > > >> clashes are a rare problem. > > >> regards Balazs > > >> > > >> On 2016-01-21 16:17, Martin Bjorklund wrote: > > >> > > >>> Balazs Lengyel <balazs.leng...@ericsson.com> wrote: > > >>> > > >>>> Hello, > > >>>> We have some instance identifiers in our model but we want to > > >>>> contrain what they can point at. What is the best method for that? > > >>>> > > >>> Unfortunately, there is no standard way of doing this. (There are > > >>> vendor extensions available...) > > >>> > > >>> [...] > > >>> > > >>> Some issues: > > >>>> - instance-identifiers don't have a canonical format, so what is > > >>>> their value in an XPath expression? > > >>>> > > >>> This is not defined. > > >>> > > >>> - I didn't find a way to evaluate a regexp in XPath 1.0. Is there a > way? > > >>>> > > >>> In YANG 1.1, there is a function re-match() for this purpose. For > > >>> your use case, it *may* work to match just the local names of all > > >>> nodes, i.e., using wildcards for the prefixes. It is not a generic > > >>> solution though. > > >>> > > >>> - if I have all the needed namespace prefixes in imports, can I just > > >>>> use them? > > >>>> > > >>> No, these prefixes are local to the module that is doing the import, > > >>> and they may or may not match the prefixes used by the implementation > > >>> when it construct the instance-identifier value. > > >>> > > >>> > > >>> > > >>> /martin > > >>> > > >>> > > >> -- > > >> Balazs Lengyel Ericsson Hungary Ltd. > > >> Senior Specialist > > >> ECN: 831 7320 > > >> Mobile: +36-70-330-7909 email: < > balazs.leng...@ericsson.com> > > >> balazs.leng...@ericsson.com > > >> > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > >> > > > > > > > > > -- > > > Balazs Lengyel Ericsson Hungary Ltd. > > > Senior Specialist > > > ECN: 831 7320 > > > Mobile: +36-70-330-7909 email: > balazs.leng...@ericsson.com > > > > > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
