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
