Andy Bierman <[email protected]> writes: > On Mon, Feb 14, 2022 at 1:19 AM Jan Lindblad (jlindbla) <[email protected]> > wrote: > >> Just to add to the complexity here, it's not only about identityrefs. >> >> People (including IETF) have also defined types that use qname:s inside >> YANG strings, which the servers and clients would have to recognize and >> treat properly in order to interoperate well. >> >> module ietf-yang-types { >> ... >> typedef xpath1.0 { >> type string; >> description >> "This type represents an XPATH 1.0 expression. >> >> When a schema node is defined that uses this type, the >> description of the schema node MUST specify the XPath >> context in which the XPath expression is evaluated."; >> reference >> "XPATH: XML Path Language (XPath) Version 1.0"; >> } >> >> > > Good point. Not just a server implementation detail I guess. > We had a YANG extension for this before this xpath type came out. > https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-xpath > > The server implementation definitely needs to know (early in the > processing) which strings are plain strings > and which are XPath expressions. Usually it is too late to get the > namespace bindings > after the XML parser is finished. > > Maybe a solution for YANG 2.0... > Create a standard algorithm to convert QName and xpath:1.0 strings to a > canonical format, > using the module-name approach defined in RFC 7951.
This is not so easy, as long as a canonical value must also stay lexically valid in a given representation. The only reasonable (but backwards incompatible) solution seems to be to change the XML encoding of identityref values to be the same as in RFC 7951. Lada > > For now, there is no real problem to solve. Supporting YANG 1.1 requires the > implementation to be aware of XML prefixes in string node content. > Leaf value comparisons involving strings with XML prefixes are not reliable. > (Maybe a whole new can of worms there...) > > > >> /jan >> >> > Andy > > >> On 14 Feb 2022, at 10:05, Ladislav Lhotka <[email protected]> wrote: >> >> Andy Bierman <[email protected]> writes: >> >> On Sat, Feb 12, 2022 at 6:57 AM Jürgen Schönwälder < >> [email protected]> wrote: >> >> I agree that this should not go forward as is. >> >> The XML representation of YANG instance data does indeed use QNames in >> element values and hence applications must be able to resolve XML >> namespace prefixes. If this is not clear enough in RFC 7950, then we >> need to address the lack of clarity where it belongs to be addressed. >> >> If we were to add a warning to all (past and) future YANG modules to >> help implementors who did not read RFC 7950, then the warning should >> be concise ("Applications using the XML representation of YANG >> instance data must be able to resolve XML namespace prefixes."). My >> preference, though, is to assume that implementors read RFC 7950 when >> they are not sure how to implement the prefixes correctly. >> >> >> It seems clear that this is not an issue specific to a particular YANG >> module, >> so the fix needs to be an errata against RFC 7950. >> The text in question is probably limited to the first paragraph (first >> sentence). >> >> 9.10.3 <https://datatracker.ietf.org/doc/html/rfc7950#section-9.10.3>. >> Lexical Representation >> >> An identityref is lexically represented as the referred identity's >> qualified name as defined in [XML-NAMES >> <https://datatracker.ietf.org/doc/html/rfc7950#ref-XML-NAMES>]. If >> the prefix is not >> present, the namespace of the identityref is the default namespace >> in effect on the element that contains the identityref value. >> >> >> >> The problem is that XML-NAMES only applies to elements and attributes (not >> string node content). >> >> >> I looked into XSLT 2.0, sec. 5.1 [1], hoping that we could use it as a >> model, but it became clear to me that we have a bigger problem: equality of >> identityref values isn't properly defined in YANG. We resolved this in YANG >> 1.1 for identityrefs appearing in XPath expressions by adding the functions >> "derived-from" and "derived-from-or-self", but the problem still persists >> e.g. when comparing identityref values serving as list keys (sec. 9.1 in >> RFC 7950 doesn't help here). >> >> Lada >> >> [1] https://www.w3.org/TR/xslt20/#qname >> >> >> I do not know the proper replacement text for the first sentence, but it >> seems maybe >> a specific definition of the expanded name for identityref: >> >> The expanded name for an identityref value consists of a namespace name >> equal >> to a module namespace (defined in 5.3) and a local name equal to an >> identity identifier. >> The reffered identity is defined within the module bound to the module >> namespace >> value. >> >> >> >> /js >> >> >> >> >> Andy >> >> >> >> On Sat, Feb 12, 2022 at 12:54:18PM +0000, tom petch wrote: >> >> Going back to the original issue and so top-posting. >> >> NSF Monitoring Interface YANG Data Model >> is on the IESG Telechat 17feb2022. >> >> It contains the text - not an easy read unless you are an XML expert - >> "In order for the XML >> data to be used correctly, the prefix (i.e., the characters before >> the colon or 'nsfmi' in the example) in the content of the element >> that uses the "identityref" type (e.g., /i2nsf-event/i2nsf-system- >> detection-alarm/alarm-category/) in the YANG module described in this >> document MUST be the same as the namespace prefix (i.e., 'nsfmi' in >> the example) for urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf- >> monitoring. Therefore, XML software MUST be chosen that makes the >> namespace prefix information available." >> >> This is the result of discussions between IANA and the XML directorate, >> >> which I have seen copied to the WG list, and seems to me to be in direct >> contradiction of the consensus of the NETMOD WG list as shown in the >> discussions this month on this thread over the DHCP I-D and a separate >> thread on the I2NSF I-D in January and is likely to be a source of >> confusion for the future. >> >> >> NSF-Facing Interface YANG Data Model >> is on the same Telechat but I do not see the same text. >> >> I would like an AD to throw a flag, in the shape of a DISCUSS so I am >> >> copying Robert. >> >> >> My take is that the text should not be included in any I-D based on the >> >> consensus of the NETMOD WG (as I perceive it). One suggestion was that it >> needed an update to RFC7950 to make it justified. >> >> >> (Also, my rant of 2022, these late stage non-WG interventions should not >> >> be over-riding the WG discussions but that is not going to change any time >> soon). >> >> >> Tom Petch >> ________________________________________ >> From: netmod <[email protected]> on behalf of tom petch < >> >> [email protected]> >> >> Sent: 11 February 2022 17:03 >> >> From: Carsten Bormann <[email protected]> >> Sent: 11 February 2022 08:21 >> >> (I’m also still not sure I’ve got an answer to my question about >> >> using inconsistent prefixes between YANG and the XML example. What is >> being demonstrated here?) >> >> >> <tp> >> If you are referring to >> " Is there a reason to violate the SHOULD?" >> >> >> I’m referring to the question I was trying to ask when I said this :-) >> >> I did not see that as related to the thread but thought it was >> >> answered anyway by Juergen. As he said, the SHOULD gets violated when >> prefix clash which, in the absence of a registry, a namespace, for prefix >> is possible. >> >> >> Yes, and thanks to him for answering my question as a general question. >> >> I was answering to a throwaway note that the authors got flak when their >> >> XML did not use the defined prefix. My question was: why do that, then? >> Maybe that was not understood because “ianaift” actually *is* the prefix >> preferred in the YANG module, so my question doesn’t make sense. (I’m not >> sure what the throwaway referred to.) >> >> >> <tp> >> >> Try again. >> >> I have commented a number of times on a YANG import which defines a >> >> prefix other than that in the RFC. Last month, it was >> >> import ietf-hardware { >> prefix ietfhw; >> Usually, when I comment on this, the authors accept my comment and >> >> change the prefix - they did on this occasion - but sometimes I get >> pushback along the lines that YANG Guidelines is only a 'SHOULD' and we >> think that we have a good reason to ignore the 'SHOULD' . To date, I have >> never agreed with the reason and go on commenting:-) If that is flack, >> then yes, I have - and will - generate flack:-) >> >> >> Tom Petch >> >> >> Grüße, Carsten >> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> -- >> Jürgen Schönwälder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 <https://www.jacobs-university.de/> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
