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

[Ladislav Lhotka <[e-mail]>]

Jernej Tuljak <[e-mail]> writes:

> 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.
>
> 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 <[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
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67