Hi,
On Thu, Feb 3, 2022 at 9:07 AM Tim Bray <[email protected]> wrote: > Hi everyone, I'm the person on the XML directorate who raised this issue > in conversation with Ian Farrer in a review of draft-ietf-dhc-dhcpv6-yang. > After a lot of back and forth, I think we came to agreement on the > necessary language to address this issue. I believe that language has. > been included in draft-ietf-i2nsf-nsf-monitoring-data-model, see > https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-13#section-10 > I do not think this is consistent with the YANG definitions for identityref in RFC 7950 https://datatracker.ietf.org/doc/html/rfc7950#section-9.10.3 Implementations use the prefixed encoding shown in 9.10.5 libxml2 has an API to get the namespace for a string node. A YANG parser needs to know identityref is handled differently than a plain string. Andy > I've excerpted an email exchange with Ian Farrer that I think makes the > potential problem concrete: > > Hi Ian, I don't think we've met. I'm the grumpy person on the "XML > Directorate" who's been whining about the namespace prefixes in YANG > internet-drafts. One quick issue: I'm a little surprised, is anyone still > using XML in this kind of thing any more in 2021? > > Anyhow, below I've excerpted the issue that's still troubling me. Here's > the XML: > > <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" > xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"> > <interface> > <name>eth0</name> > <type>ianaift:ethernetCsmacd</type> > <description>DHCPv6 Relay Interface</description> > <enabled>true</enabled> > </interface> > </interfaces> > > So my question is, I see the XML namespace prefix and the prefix for the > <type> element content are identical. Is this a coincidence? For example, > would the following work, changing the namespace prefix to "foo"? > > > <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" > xmlns:foo="urn:ietf:params:xml:ns:yang:iana-if-type"> > <interface> > <name>eth0</name> > <type>ianaift:ethernetCsmacd</type> > <description>DHCPv6 Relay Interface</description> > <enabled>true</enabled> > </interface> > </interfaces> > > [if - This example would not work and fails validation with yanglint: > > $ yanglint --strict --verbose -t config -p $IETFYANG > $IETFYANG/iana-if-type.yang $IETFYANG/ietf-interfaces.yang test1.xml > err : Invalid value "ianaift:ethernetCsmacd" in "type" element. > (/ietf-interfaces:interfaces/interface[name='eth0']/type) > ] > > > Follow-up, would the following work, foo for both namespace and content > prefix? > > <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" > xmlns:foo="urn:ietf:params:xml:ns:yang:iana-if-type"> > <interface> > <name>eth0</name> > <type>foo:ethernetCsmacd</type> > <description>DHCPv6 Relay Interface</description> > <enabled>true</enabled> > </interface> > </interfaces> > > Thanks in advance! > > > [if - This does validate with yanglint, however the convention in the IETF > examples I’ve seen seems to be to use the prefix that is defined in the > original YANG module for imports for consistency, e.g. (from > iana-if-type.yang): > > > On Thu, Feb 3, 2022 at 8:03 AM Andy Bierman <[email protected]> wrote: > >> Hi, >> >> I think the text from sec 4 refers to the usage within an application. >> The XML instance document is the on-the-wire representation and >> the I-D example looks correct. >> >> https://www.w3.org/TR/xml-names/#ns-qualnames >> >> >> Andy >> >> >> On Thu, Feb 3, 2022 at 3:53 AM tom petch <[email protected]> wrote: >> >>> From: netmod <[email protected]> on behalf of [email protected] < >>> [email protected]> >>> Sent: 03 February 2022 09:37 >>> >>> Hi, >>> >>> A draft I have been working on ( >>> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/) contains >>> a number of XML configuration examples. During the XML expert review, a >>> question has been raised about the use of XML namespaces in these examples. >>> I’m raising it here as I don’t have the XML knowledge to answer. >>> >>> <tp> >>> >>> Ian >>> >>> This looks like the issue I raised on this list 14jan2022 with a subject >>> line of >>> XML and prefix >>> although I have not checked that the usage is exactly the same; the 'XML >>> Expert' comment would appear to be. >>> >>> Tom Petch >>> >>> In my example: >>> >>> <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" >>> >>> xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"> >>> <interface> >>> <name>eth0</name> >>> <type>ianaift:ethernetCsmacd</type> >>> <description>DHCPv6 Relay Interface</description> >>> <enabled>true</enabled> >>> </interface> >>> </interfaces> >>> >>> The question is related to the use of the ‘ianaift:’ prefix. This is >>> quite commonly use in XML examples in YANG documents (e.g. RFC8344) so I >>> think the question is generally applicable. >>> >>> The specific comments from the expert review are: >>> >>> - >>> For the correct processing of these documents requires that whatever XML >>> software is being used makes available to application code the namespace >>> prefixes. >>> >>> Whilst the recommended tools (e.g. yanglint) provides this function, it >>> is not an XML best practice. Quoting from the Namespaces in XML, section 4: >>> "Note that the prefix functions only as a placeholder for a namespace name. >>> Applications SHOULD use the namespace name, not the prefix, in constructing >>> names whose scope extends beyond the containing document.” >>> >>> I think that violating a SHOULD assertion in a W3C standard is a problem. >>> >>> There is no requirement for XML processors to provide this prefix >>> information, and software that (quite legally) doesn't, will not work >>> correctly with YANG documents constructed as specified in this I-D. >>> >>> 1, YANG specifications should note this fact and specify that software >>> which is used to process YANG documents MUST provide an interface such that >>> applications can retrieve the prefix-namespace mappings. >>> 2, For constructs such as <type>ianaift:ethernetCsmacd</type> the >>> Internet-Draft should specify that the prefix ("ianaift" in this case) MUST >>> be identical to the xmlns namespace prefix representing the namespace name >>> urn:ietf:params:xml:ns:yang:iana-if-type >>> 3, Alternately, the draft could specify that for the namespace >>> urn:ietf:params:xml:ns:yang:iana-if-type, the XML namespace prefix ianaift >>> MUST be used. Another XML bad practice because software that generates XML >>> programmatically should feel free to generate synthetic prefixes without >>> breaking the content, but at least this would solve the problem. >>> - >>> >>> BCP216 (RFC8407 - Guidelines for Authors and Reviewers of Documents >>> Containing YANG modules) doesn’t make any mention of how XML namespaces >>> should be used, only that example XML/ JSON should be included and that >>> these examples need to be validated (pyang and yanglint are mentioned for >>> this). >>> >>> Does this guidance need to be updated to reflect expert review comments >>> above? >>> >>> Thanks, >>> Ian >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
