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

[Andy Bierman <[e-mail]>]

Hi,


On Thu, Feb 3, 2022 at 9:07 AM Tim Bray <[e-mail]> wrote:

> Hi everyone, I'm the person on the XML directorate who raised this issue
> in conversation with Ian Farrer in a review of draft-ietf-dhc-dhcpv6-yang.
> After a lot of back and forth, I think we came to agreement on the
> necessary language to address this issue.  I believe that language has.
> been included in draft-ietf-i2nsf-nsf-monitoring-data-model, see
> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-13#section-10
>


I do not think this is consistent with the YANG definitions for identityref
in RFC 7950
 https://datatracker.ietf.org/doc/html/rfc7950#section-9.10.3

Implementations use the prefixed encoding shown in 9.10.5

libxml2 has an API to get the namespace for a string node.
A YANG parser needs to know identityref is handled differently than a plain
string.


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
>>>
>>