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

[Martin Björklund <[e-mail]>]

Jernej Tuljak <[e-mail]> wrote:
> 
> 
> On 04/02/2022 08:18, Martin Björklund wrote:
> > Tim Bray <[e-mail]> wrote:
> >> 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.
> > 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 <[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
> >>>>>>>>
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>