Hi Tim,

See inline with [mj] as I cannot seem to insert my comments between the text 
without distinguishing it from the rest of the thread.

> On Feb 3, 2022, at 9:07 AM, Tim Bray <[email protected]> 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
>  
> <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-13#section-10>
> 
> 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)
> ]
> 
> [mj] It would work if the type field used the prefix that was defined, i.e.
> <type>foo:ethernetCsmacd</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):
> 
> [mj] That is correct. We have been beaten up enough number of times for not 
> using the prefix defined by the YANG module. Is the suggestion to state that 
> in the draft?
> 
> 
> On Thu, Feb 3, 2022 at 8:03 AM Andy Bierman <[email protected] 
> <mailto:[email protected]>> 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 
> <https://www.w3.org/TR/xml-names/#ns-qualnames>
> 
> 
> Andy
> 
> 
> On Thu, Feb 3, 2022 at 3:53 AM tom petch <[email protected] 
> <mailto:[email protected]>> wrote:
> From: netmod <[email protected] <mailto:[email protected]>> on 
> behalf of [email protected] <mailto:[email protected]> <[email protected] 
> <mailto:[email protected]>>
> Sent: 03 February 2022 09:37
> 
> Hi,
> 
> A draft I have been working on 
> (https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/ 
> <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
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
[email protected]






_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to