Re: [netmod] Use XML namespaces in YANG document examples

[Tim Bray <[e-mail]>]

On Thu, Feb 3, 2022 at 10:21 AM Martin Björklund <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> wrote:
> > >>>
> > >>>> From: netmod <[e-mail]> on behalf of
> [e-mail] <
> > >>>> [e-mail]>
> > >>>> 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
> > >>>> [e-mail]
> > >>>> https://www.ietf.org/mailman/listinfo/netmod
> > >>>>
> > >>>
>