Hi Ian,

[email protected] writes:

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

The present situation is IMO different: the prefix doesn't leak out of the 
containing document, it is only used for something else than XML element and 
attribute names. The "ianaift" prefix can be replaced by something else, and it 
should be transparent to the outside world. So I don't think this SHOULD is 
relevant in this case.

Lada

>
> 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]
> https://www.ietf.org/mailman/listinfo/netmod

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

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

Reply via email to