Jernej Tuljak <[email protected]> writes: > On 04/02/2022 08:18, Martin Björklund wrote: >> Tim Bray <[email protected]> wrote: >>> On Thu, Feb 3, 2022 at 10:21 AM Martin Björklund <[email protected]> wrote: >>> >>>> If an XML document has <foo xmlns:bar="...">, won't the XML processor >>>> pass the attribute "xmlns:bar" and its value to the application? This >>>> should be enough even if the XML processor doesn't provide a mapping >>>> table between prefix and namespace (it requires more work in the >>>> application of course). >>>> >>> Nope, there's no requirement that they do and some don't. >> Does this mean that an XML processor might not pass attributes in >> general to the application? If so, we might have other similar >> problems. Or does it mean that an XML processor might just not pass >> these "special" attributes? If so, where is that specified? (I tried >> to find this info in the spec, but didn't find it). > > Names that start with "xml" (case insensitive) are reserved by XML 1.0 > specification, "xmlns" in an attribute name included (2.3 Common > Syntactic Constructs). They are special. There is also a guideline on > colon usage within names. > > All processors I'm aware of differentiate between attributes and > namespace attributes in their APIs. What Tim is probably saying is that > some XML processors either don't implement Namespaces in XML 1.0 or need > to be explicitly configured to become "namespace aware". If not > configured as namespace aware, they might simply ignore namespace > attributes therefore not passing them. If they are configured as > namespace aware, they might remove prefix information and pass only > "namespace : local-name" pairs where required (and that excludes text > node content).
Right, and "namespace" here means a full namespace URI. Lada > > Jernej > >> >> >> /martin >> >> >>>> I think that if special text is needed for identityref values in XML, >>>> that text should go in to the YANG specification (RFC 7950). All >>>> these other drafts just follow the rules defined in RFC 7950. >>>> >>> Agreed. >>> >>> >>> >>>> >>>> /martin >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> 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 > > _______________________________________________ > 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
