Jernej Tuljak <[email protected]> wrote: > > > 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.
Yes, I know. But I can't see that the spec says that attributes w/ reserved names should be treated differently wrt. the application than other attributes. > 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). I guess I wonder if this is b/c the specification says so, or that some implementations choose to do so. /martin > > 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
