On Thu, Feb 3, 2022 at 10:21 AM Martin Björklund <mbj+i...@4668.se> 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. > 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 <a...@yumaworks.com> > 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 <ie...@btconnect.com> > wrote: > > >>> > > >>>> From: netmod <netmod-boun...@ietf.org> on behalf of > ianfar...@gmx.com < > > >>>> ianfar...@gmx.com> > > >>>> 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 > > >>>> netmod@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/netmod > > >>>> > > >>> >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
