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

From: [email-masked]
Date: Thu, 3 Feb 2022 10:37:03 +0100

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

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

---

From: tom petch <[email-masked]>
Date: Thu, 3 Feb 2022 11:53:24 +0000

From: netmod <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: 03 February 2022 09:37

Hi,

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

-

Thanks,
Ian

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Feb 2022 08:03:30 -0800

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 <[email-masked]> wrote:

> 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
>
> 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.
>
> 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.”
>
> 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).
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Tim Bray <[email-masked]>
Date: Thu, 3 Feb 2022 09:07:38 -0800

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

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 <[email-masked]> wrote:

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 3 Feb 2022 09:43:49 -0800

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-masked]> 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:
>> 
>> 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"?
> 
>> 
> $ 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.
>> Follow-up, would the following work, foo for both namespace and content prefix?
>> 
> [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-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> 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-masked] <mailto:[email-masked]>> wrote:
> From: netmod <[email-masked] <mailto:[email-masked]>> on behalf of [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> 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
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Feb 2022 09:46:35 -0800

Hi,

On Thu, Feb 3, 2022 at 9:07 AM Tim Bray <[email-masked]> 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.

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

>>> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/) contains
>>> a number of XML configuration examples. During the XML expert review, a

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 Feb 2022 18:48:37 +0100

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

RFC 7950, Section 7.1.4:

   When used inside the "import" statement, the "prefix" statement
   defines the prefix to be used when accessing definitions inside the
   imported module.  When a reference to an identifier from the imported
   module is used, the prefix string for the imported module followed by
   a colon (":") and the identifier is used, e.g., "if:ifIndex".  To
   improve readability of YANG modules, the prefix defined by a module
   SHOULD be used when the module is imported, unless there is a
   conflict.  If there is a conflict, i.e., two different modules that
   both have defined the same prefix are imported, at least one of them
   MUST be imported with a different prefix.

Is there a reason to violate the SHOULD?

Grüße, Carsten

---

From: Tim Bray <[email-masked]>
Date: Thu, 3 Feb 2022 09:49:26 -0800

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

Yes, or more simply, the suggestion is to just say what's going on: That
the prefix you use inside the element has to be the same as the prefix
attached to the
particular YANG namespace. And because of that, to process YANG correctly
you need to use an XML tool that makes available the namespace/prefix
mappings.

I think for YANG people this is all just understood and wired into the
software tools. But since it's a constraint that could cause failure to
interoperate I think it should be
stated explicitly.

On Thu, Feb 3, 2022 at 9:43 AM Mahesh Jethanandani <[email-masked]>
wrote:

> 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.
>
> [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?
>
>

---

From: Tim Bray <[email-masked]>
Date: Thu, 3 Feb 2022 09:54:16 -0800

> libxml2 has an API to get the namespace for a string node.

Just to get the terms correct, it's not the "namespace" you need to get,
you need to get the XML prefix mapped to that namespace, and the prefix has
to be the same inside the element.

Not all XML is processed with libxml2, and not all XML processors make the
namespace prefixes available, and such processors won't be able to process
these YANG instances correctly.

> A YANG parser needs to know identityref is handled differently than a
> plain string.
>
Exactly.  In particular, it must uses prefixes that are consistent with
those declared in the "xmlns:whatever" attribute. So, the RFC should say
that.

>> [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):
>>
>>
>>>> For the correct processing of these documents requires that whatever
>>>> XML software is being used makes available to application code the
>>>> namespace prefixes.
>>>>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Feb 2022 10:04:01 -0800

Hi,

I think the text in 7950 is clear enough.
The examples for identityref use prefix strings that are not the YANG
prefix.
The prefix value is arbitrary and it just needs to match an xmlns attribute.
Are you saying sections 9.10.3 and 9.10.5 are wrong and need to be changed?

Andy

On Thu, Feb 3, 2022 at 9:54 AM Tim Bray <[email-masked]> wrote:

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

---

From: Martin Björklund <[email-masked]>
Date: Thu, 03 Feb 2022 19:20:43 +0100 (CET)

Hi,

> these YANG instances correctly.

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

> those declared in the "xmlns:whatever" attribute. So, the RFC should say

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.

/martin

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 3 Feb 2022 19:51:34 +0100

The quoted text applies to the resolutione of foo:bar within YANG,
which is different from resolving foo:bar within an XML serialized
data tree.

> Is there a reason to violate the SHOULD?

There is no global registry of prefixes, hence collisions in the
prefix namespace can occur.

/js

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Tim Bray <[email-masked]>
Date: Thu, 3 Feb 2022 10:55:21 -0800

> table between prefix and namespace (it requires more work in the

Nope, there's no requirement that they do and some don't.

> these other drafts just follow the rules defined in RFC 7950.

Agreed.

> > >>>> From: netmod <[email-masked]> on behalf of
> [email-masked] <
> > >>>> [email-masked]>
> contains
> > >>>> Does this guidance need to be updated to reflect expert review
> comments
> > >>>> above?
> > >>>>
> > >>>> Thanks,
> > >>>> Ian
> > >>>>
> > >>>>
> > >>>>

---

From: Tim Bray <[email-masked]>
Date: Thu, 3 Feb 2022 13:53:29 -0800

> Are you saying sections 9.10.3 and 9.10.5 are wrong and need to be changed?

I think10.9.3 is correct? I *guess* you could look at “An identityref is
lexically represented as the referred identity's qualified name as defined
in [XML-NAMES]” and infer something like "…and when used in an XML
definition, the prefix in the qualified name must be identical to the one
used in the XML namespace declaration."  Because [XML-NAMES] says nothing
about using these prefixes anywhere but to prefix element and attribute
names, so referring to it here doesn't really help that much.

Then if you look at 9.10.5  "Usage Examples", the examples make it pretty
clear what's happening, and that the namespace prefix has to be used in the
element.

But, I think that since this is not an XML best practice, practitioners
should be warned that their XML infrastructure has to be capable of this
optional behavior.

By the way, everywhere else in 7950, when you have an xmlns:whatever=
definition, the "whatever" prefix is used in the intended way, in front of
element and attribute names. So really, this one "Usage Examples" section
is the only place where it's explicit what's going on.
So: No, those sections aren't wrong. Yes, in an ideal world they should be
changed. Or, just put the language in future YANG-related RFCs. It's a
short paragraph.

>> Not all XML is processed with libxml2, and not all XML processors make
>> the namespace prefixes available, and such processors won't be able to
>> process these YANG instances correctly.
>>
>>
>>>> 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"?
>>>>
>>>>
>>>>>> 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.
>>>>>> comments above?

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 3 Feb 2022 23:36:18 +0100

> should be warned that their XML infrastructure has to be capable of this

<https://www.w3.org/2001/tag/doc/qnameids> may be relevant background
reading. This document seems to acknowledge that references to
prefixes may indeed exist in attribute values or element
content. Section 5 says:

  "[...] it is already established practice.

  It is simply not practical to suggest that this usage should be
  forbidden on architectural grounds.

It seems that XML schema's QName type has similar issues like YANG's
identityref type regarding the need to map prefixes to namespace URI.
 
> is the only place where it's explicit what's going on.

The YANG leafs are typed and most types are harmless. A schema aware
processor will know which XML elements can carry prefixed values.

> changed. Or, just put the language in future YANG-related RFCs. It's a

The IETF meanwhile has ~55 published RFCs that contain YANG modules
(and the industry has way more YANG modules). I am not sure how
meaningful it is to start now to put language into all future RFCs
that contain YANG modules to warn people that they will need an XML
parser that exposes prefix to namespace URI bindings. (And then there
are like other RFCs that used XSD QNames that may require a similar
warning.)

/js

---

From: Martin Björklund <[email-masked]>
Date: Fri, 04 Feb 2022 08:18:41 +0100 (CET)

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

/martin

> > the
> > software

---

From: Jernej Tuljak <[email-masked]>
Date: Fri, 4 Feb 2022 12:36:50 +0100

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

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 04 Feb 2022 14:36:04 +0100

Hi Tim,

Tim Bray <[email-masked]> writes:

...

> <type> element content are identical. Is this a coincidence?  For example,

This is not unprecedented. For example, XSLT, W3C XML Schema and RELAX NG do essentially the same: they all use XML namespace prefixes in the values of XML attributes.

> would the following work, changing the namespace prefix to "foo"?

No, The "ianaift" prefix has to be defined as an XML namespace prefix.

I guess most people in the YANG community now agree that it would be better to use the YANG module name rather than XML namespace prefixes for qualifying identities etc. (as it is in the JSON representation), but it is now too late.

Lada

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 04 Feb 2022 14:50:45 +0100

> "namespace : local-name" pairs where required (and that excludes text 

Right, and "namespace" here means a full namespace URI.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 04 Feb 2022 15:00:32 +0100

Hi Ian,

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

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

---

From: Martin Björklund <[email-masked]>
Date: Fri, 04 Feb 2022 16:15:36 +0100 (CET)

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

> 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

I guess I wonder if this is b/c the specification says so, or that
some implementations choose to do so.

/martin

---

From: [email-masked]
Date: Mon, 7 Feb 2022 20:40:49 +0100

Hi,

Reading back through the discussion, I think I can summarise the outcome to the following 2 points:

1,The examples in the DHCPv6 YANG draft can keep the current use of XML prefixes (e.g. ianaift:ethernetCsmacd)

2, In the XML examples appendix, I will change the first paragraph to read:

XML Examples for DHCPv6 Element Configuration

This section contains XML examples of data trees for the different
DHCPv6 elements. In order for the XML data to be used correctly,
the XML prefix must be the same as the namespace prefix. i.e, for
The client configuration example, the characters before the colon
(or 'ianaift:’ in the "interface/type” element content) must match the
xmlns defined for "urn:ietf:params:xml:ns:yang:iana-if-type”. In this
case xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type”.
Therefore, XML software must be chosen that makes the namespace prefix
information available.

Does this sound like the right way to proceed?

Thanks,
Ian

> On 4. Feb 2022, at 16:15, Martin Björklund <[email-masked]> wrote:
>

---

From: Tim Bray <[email-masked]>
Date: Mon, 7 Feb 2022 11:41:31 -0800

LGTM.

On Mon, Feb 7, 2022 at 11:40 AM <[email-masked]> wrote:

> I've excerpted an email exchange with Ian Farrer that I think makes
>
> the
>
> internet-drafts. One quick issue: I'm a little surprised, is anyone
>
> still
>
> Anyhow, below I've excerpted the issue that's still troubling me.
>
> Here's
>
> the XML:
>
> <type> element content are identical. Is this a coincidence?  For
>
> example,
>
> Follow-up, would the following work, foo for both namespace and
>
> content
>
> prefix?
>
> IETF examples I’ve seen seems to be to use the prefix that is defined
>
> in
>
> On Thu, Feb 3, 2022 at 8:03 AM Andy Bierman <[email-masked]>
>
> wrote:
>
> Hi,
>
> I think the text from sec 4 refers to the usage within an
>
> application.
>
> On Thu, Feb 3, 2022 at 3:53 AM tom petch <[email-masked]>
>
> wrote:
>
> 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.
>
> quite commonly use in XML examples in YANG documents (e.g. RFC8344)
>
> so I
>
> 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
>
> information, and software that (quite legally) doesn't, will not
>
> work
>
> which is used to process YANG documents MUST provide an interface
>
> such that
>
> 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, 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
>
> 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).
>

---

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 7 Feb 2022 21:03:04 +0100

While adding such a disclaimer may help you to move your document
forward (which I assume is your main priority), this looks to me like
a disclaimer added to an arbitrary YANG document for the sake of
making a reviewer happy while (i) we never did this before and (ii) we
likely have no plan to do this in the future.

If this issue is really important, then someone should write an I-D or
an errata for RFC 7950 that clarifies this for _all_ YANG modules.

Given that YANG is 11+ years old, I am not convinced this clarification
is needed, but that certainly may be a biased opinion.

Hence, my preference is to add no disclaimer and to move forward.

/js

---

From: Tim Bray <[email-masked]>
Date: Mon, 7 Feb 2022 12:56:02 -0800

I can see your point, and I'm not trying to get in YANG's way.  From my
PoV, I think the question I'm being asked to answer is "Does this RFC
provide the information needed to build an interoperable implementation?"
And on the XML front, it does a weak job, which I pointed out, and provided
text which would address that weakness. Whatever you decide to do, I guess
I should file an erratum against 7950; any objection to that?

On Mon, Feb 7, 2022 at 12:03 PM Jürgen Schönwälder <
[email-masked]> wrote:

> > >>>>>>>> On Thu, Feb 3, 2022 at 8:03 AM Andy Bierman <[email-masked]
> >
> > >>>>> wrote:
> > >>>>>>>>> Hi,
> > >>>>>>>>>
> > >>>>>>>>>> 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"
> > >>>>>>>>>>
> > >>>>>>>>>> I think that violating a SHOULD assertion in a W3C standard
> is a
> > >>>>>>>>>> problem.
> > >>>>>>>>>>

---

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 7 Feb 2022 22:13:28 +0100

The XML encoding rules are part of RFC 7950, I do not think this
document has to clarify the properties of these encoding rules. Since
this document normatively depends on RFC 7950, I think it can be
expected that implementors understand RFC 7950.

You can of course file an erratum against RFC 7950, I assume it will
go through the usual process and the WG will discuss it.

/js

---

From: tom petch <[email-masked]>
Date: Thu, 10 Feb 2022 12:22:29 +0000

From: netmod <[email-masked]> on behalf of Jürgen Schönwälder <[email-masked]>
Sent: 07 February 2022 20:03

<tp>

Spot on.

I see a functional problem with expert reviews at a late stage in the process. I have had a lot of problems with them in the past year or two and almost always they arise because the expert is viewing the work from the limited point of view of their expertise and not seeing the work as part of the output of the IETF, a large existing body of work which I believe needs to be coherent (a favorite word of mine).

If the comments in question had been made at the time of RFC7950 they would have been most insightful; now they are not IMHO.

I also see it as symptomatic that this issue was raised over an I2NSF I-D which I brought to the attention of the NETMOD WG earlier this year and would say that the consensus of the WG at that time was that the comment was unjustified.  Now we get the same comment on DHCP.  How many more times is it going to come up?

On  a bad day, I see experts descending from an ivory tower, causing mayhem and disappearing until the next time but I admit that that is an extreme view.  Expert opinions are useful input but should be just input to the consensus whereas at times, especially at Last Call, they may be taken at gospel to the detriment of the cohesion of the IETF.

Tom Petch
/js

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Feb 2022 13:43:23 +0100

> If the comments in question had been made at the time of RFC7950 they would have been most insightful; now they are not IMHO.

The comment is insightful, it is just not about this document.
I think we need to be able to sort comments into the right bins.
(And we need to formalize “Hold for document update” bins for non-errata.)

(I’m also still not sure I’ve got an answer to my question about using inconsistent prefixes between YANG and the XML example.  What is being demonstrated here?)

Grüße, Carsten

---

From: tom petch <[email-masked]>
Date: Thu, 10 Feb 2022 17:09:39 +0000

Trimming the cc:

From: Carsten Bormann <[email-masked]>
Sent: 10 February 2022 12:43

<tp>
If you are referring to
" Is there a reason to violate the SHOULD?"
I did not see that as related to the thread but thought it was answered anyway by Juergen.  As he said, the SHOULD gets violated when prefix clash which, in the absence of a registry, a namespace, for prefix is possible. Within the IETF we ought to be able to avoid clashes although good hygiene, like not using two letter prefix helps but there is a world of YANG out there most of which we likely know little of.

But the thread was about where prefix may be used and Tim was proposing a different prefix  in the XML content.  XML defined a namespace for identifiers using a URI, which is clunky, so like many specifications, a short form is created, the prefix, with a mapping thereto.  The question then is where is it permissible to use the short form, where the mapping will be understood.  I have not looked at the language specification lately but the quotes from it in this thread suggested that it is ok in entity and attribute but not in XML content and needs redefining there except that this is YANG and this is identityref and any parser that does not understand the nature of identityref is a lost cause.  

But that is at the limit of my understanding (until I re-read the XML specification).  I am clear that I think that we are ok with what we are doing and should not start introducing new boiler plate for future examples of YANG.

Tom Petch

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Feb 2022 09:21:14 +0100

> " Is there a reason to violate the SHOULD?"

I’m referring to the question I was trying to ask when I said this :-)

> I did not see that as related to the thread but thought it was answered anyway by Juergen.  As he said, the SHOULD gets violated when prefix clash which, in the absence of a registry, a namespace, for prefix is possible.

Yes, and thanks to him for answering my question as a general question.

I was answering to a throwaway note that the authors got flak when their XML did not use the defined prefix.  My question was: why do that, then?  Maybe that was not understood because “ianaift” actually *is* the prefix preferred in the YANG module, so my question doesn’t make sense.  (I’m not sure what the throwaway referred to.)

Grüße, Carsten

---

From: tom petch <[email-masked]>
Date: Fri, 11 Feb 2022 17:03:50 +0000

From: Carsten Bormann <[email-masked]>
Sent: 11 February 2022 08:21

<tp>

Try again.

I have commented a number of times on a YANG import which defines a prefix other than that in the RFC.  Last month, it was
     import ietf-hardware {
       prefix ietfhw;
Usually, when I comment on this, the authors accept my comment and change the prefix - they did on this occasion - but sometimes I get pushback along the lines that YANG Guidelines is only a 'SHOULD' and we think that we have a good reason to ignore the 'SHOULD' .  To date, I have never agreed with the reason and go on commenting:-)  If that is flack, then yes, I have - and will - generate flack:-)

Tom Petch

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Feb 2022 09:32:40 -0800

On Fri, Feb 11, 2022 at 9:04 AM tom petch <[email-masked]> wrote:

> >> (I’m also still not sure I’ve got an answer to my question about using
> inconsistent prefixes between YANG and the XML example.  What is being
> demonstrated here?)
> >>
> > <tp>
> > If you are referring to
> > I did not see that as related to the thread but thought it was answered
> anyway by Juergen.  As he said, the SHOULD gets violated when prefix clash
> which, in the absence of a registry, a namespace, for prefix is possible.
>
> I was answering to a throwaway note that the authors got flak when their
> XML did not use the defined prefix.  My question was: why do that, then?
> Maybe that was not understood because “ianaift” actually *is* the prefix
> preferred in the YANG module, so my question doesn’t make sense.  (I’m not
> sure what the throwaway referred to.)
>
>
A prefix in an XML instance document and a prefix in a YANG document are
separate
and the rules for each are separate.  An implementation MUST handle any
prefix used
in either case.

<tp>
>
> Try again.
>
> I have commented a number of times on a YANG import which defines a prefix
> other than that in the RFC.  Last month, it was
>      import ietf-hardware {
>        prefix ietfhw;
> Usually, when I comment on this, the authors accept my comment and change
> the prefix - they did on this occasion - but sometimes I get pushback along
> the lines that YANG Guidelines is only a 'SHOULD' and we think that we have
> a good reason to ignore the 'SHOULD' .  To date, I have never agreed with
> the reason and go on commenting:-)  If that is flack, then yes, I have -
> and will - generate flack:-)
>

This is a readability issue and I agree with your efforts to enforce this
SHOULD.
It MAY be ignored only if usage of an assigned prefix would cause a conflict
(because 2 imported modules defined the same prefix-stmt value).

Andy

---

From: tom petch <[email-masked]>
Date: Sat, 12 Feb 2022 12:54:18 +0000

Going back to the original issue and so top-posting.

NSF Monitoring Interface YANG Data Model
is on the IESG Telechat  17feb2022.

It contains the text - not an easy read unless you are an XML expert - 
"In order for the XML
   data to be used correctly, the prefix (i.e., the characters before
   the colon or 'nsfmi' in the example) in the content of the element
   that uses the "identityref" type (e.g., /i2nsf-event/i2nsf-system-
   detection-alarm/alarm-category/) in the YANG module described in this
   document MUST be the same as the namespace prefix (i.e., 'nsfmi' in
   the example) for urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-
   monitoring.  Therefore, XML software MUST be chosen that makes the
   namespace prefix information available."

This is the result of discussions between IANA and the XML directorate, which I have seen copied to the WG list, and seems to me to be in direct contradiction of the consensus of the NETMOD WG list as shown in the discussions this month on this thread over the DHCP I-D and a separate thread on the I2NSF I-D in January and is likely to be a source of confusion for the future.  

 NSF-Facing Interface YANG Data Model  
is on the same Telechat but I do not see the same text.

I would like an AD to throw a flag, in the shape of a DISCUSS so I am copying Robert.

My take is that the text should not be included in any I-D based on the consensus of the NETMOD WG (as I perceive it).  One suggestion was that it needed an update to RFC7950 to make it justified.

(Also, my rant of 2022, these late stage non-WG interventions should not be over-riding the WG discussions but that is not going to change any time soon).

Tom Petch
________________________________________
From: netmod <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 11 February 2022 17:03

<tp>

Try again.

Tom Petch

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 12 Feb 2022 14:12:31 +0100

Let me try to restate in more general terms the technical side of what Tom said:

On 2022-02-12, at 13:54, tom petch <[email-masked]> wrote:
> 
> MUST be the same as the namespace prefix (i.e., 'nsfmi' in
>   monitoring. 

This is confusing language.  I don’t know what “the namespace prefix for X” is.
(Of course, I know what xmlns attributes are; are these meant here?  Or the prefix declaration in the YANG that imports the module with this name?  Or the prefix declaration in the YANG of the module with this name?)

More importantly, this is a specific instance of an antipattern that needs to be stamped out:
Rephrasing requirements of a base normative reference (here: RFC 7950) in a derived specification.
This incurs a strong danger (which is NOT theoretical):

— the rephrasing may be inaccurate and thus create a fork of the actually intended general requirement of the base standard.
— the rephrasing may be misunderstood as a requirement specific to the derived standard, so implementers feel compelled to do something special for the derived standard, again creating a fork on the implementation side.

I would like to ask that we never ever do that, except possibly with a strong indication that the restatement is just a reminder rephrasing the normative requirements of the base document.  Such a restatement needs to be clearly labeled as an informational note and needs to reference the specific normative statement in the base document that it is an instance of.

More specifically, an RFC 2119 keyword is misplaced here — this is not a new normative requirement, just a factual statement about what that base standard already requires.

Grüße, Carsten

---

From: Jürgen Schönwälder <[email-masked]>
Date: Sat, 12 Feb 2022 15:56:40 +0100

I agree that this should not go forward as is.

The XML representation of YANG instance data does indeed use QNames in
element values and hence applications must be able to resolve XML
namespace prefixes. If this is not clear enough in RFC 7950, then we
need to address the lack of clarity where it belongs to be addressed.

If we were to add a warning to all (past and) future YANG modules to
help implementors who did not read RFC 7950, then the warning should
be concise ("Applications using the XML representation of YANG
instance data must be able to resolve XML namespace prefixes."). My
preference, though, is to assume that implementors read RFC 7950 when
they are not sure how to implement the prefixes correctly.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 12 Feb 2022 08:49:16 -0800

> they are not sure how to implement the prefixes correctly.
It seems clear that this is not an issue specific to a particular YANG
module,
so the fix needs to be an errata against RFC 7950.
The text in question is probably limited to the first paragraph (first
sentence).

9.10.3 <https://datatracker.ietf.org/doc/html/rfc7950#section-9.10.3>.
Lexical Representation

   An identityref is lexically represented as the referred identity's
   qualified name as defined in [XML-NAMES
<https://datatracker.ietf.org/doc/html/rfc7950#ref-XML-NAMES>].  If
the prefix is not
   present, the namespace of the identityref is the default namespace
   in effect on the element that contains the identityref value.

The problem is that XML-NAMES only applies to elements and attributes (not
string node content).

I do not know the proper replacement text for the first sentence, but it
seems maybe
a specific definition of the expanded name for identityref:

   The expanded name for an identityref value consists of a namespace name
equal
   to a module namespace (defined in 5.3) and a local name equal to an
identity identifier.
   The reffered identity is defined within the module bound to the module
namespace
   value.

/js

Andy

> > This is the result of discussions between IANA and the XML directorate,
> which I have seen copied to the WG list, and seems to me to be in direct
> contradiction of the consensus of the NETMOD WG list as shown in the
> discussions this month on this thread over the DHCP I-D and a separate
> thread on the I2NSF I-D in January and is likely to be a source of
> confusion for the future.
> >
> > My take is that the text should not be included in any I-D based on the
> consensus of the NETMOD WG (as I perceive it).  One suggestion was that it
> needed an update to RFC7950 to make it justified.
> >
> > (Also, my rant of 2022, these late stage non-WG interventions should not
> be over-riding the WG discussions but that is not going to change any time
> soon).
> >
> > Tom Petch
> > >> (I’m also still not sure I’ve got an answer to my question about
> using inconsistent prefixes between YANG and the XML example.  What is
> being demonstrated here?)
> > >>
> > > <tp>
> > > If you are referring to
> > > I did not see that as related to the thread but thought it was
> answered anyway by Juergen.  As he said, the SHOULD gets violated when
> prefix clash which, in the absence of a registry, a namespace, for prefix
> is possible.
> >
> > I have commented a number of times on a YANG import which defines a
> prefix other than that in the RFC.  Last month, it was
> >      import ietf-hardware {
> >        prefix ietfhw;
> > Usually, when I comment on this, the authors accept my comment and
> change the prefix - they did on this occasion - but sometimes I get
> pushback along the lines that YANG Guidelines is only a 'SHOULD' and we
> think that we have a good reason to ignore the 'SHOULD' .  To date, I have
> never agreed with the reason and go on commenting:-)  If that is flack,
> then yes, I have - and will - generate flack:-)
> >
> > Tom Petch
> >
> >
> > Grüße, Carsten
> >
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Feb 2022 10:05:18 +0100

> The problem is that XML-NAMES only applies to elements and attributes (not

I looked into XSLT 2.0, sec. 5.1 [1], hoping that we could use it as a model, but it became clear to me that we have a bigger problem: equality of identityref values isn't properly defined in YANG. We resolved this in YANG 1.1 for identityrefs appearing in XPath expressions by adding the functions "derived-from" and "derived-from-or-self", but the problem still persists e.g. when comparing identityref values serving as list keys (sec. 9.1 in RFC 7950 doesn't help here).

Lada

[1] https://www.w3.org/TR/xslt20/#qname

---

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Mon, 14 Feb 2022 09:19:41 +0000

Just to add to the complexity here, it's not only about identityrefs.

People (including IETF) have also defined types that use qname:s inside YANG strings, which the servers and clients would have to recognize and treat properly in order to interoperate well.

module ietf-yang-types {
...
  typedef xpath1.0 {
    type string;
    description
     "This type represents an XPATH 1.0 expression.

      When a schema node is defined that uses this type, the
      description of the schema node MUST specify the XPath
      context in which the XPath expression is evaluated.";
    reference
     "XPATH: XML Path Language (XPath) Version 1.0";
  }

/jan

On 14 Feb 2022, at 10:05, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:

Andy Bierman <[email-masked]<mailto:[email-masked]>> writes:

On Sat, Feb 12, 2022 at 6:57 AM Jürgen Schönwälder <
[email-masked]<mailto:[email-masked]>> wrote:

Lada

/js

Andy

I would like an AD to throw a flag, in the shape of a DISCUSS so I am
copying Robert.

Tom Petch
________________________________________
From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of tom petch <
[email-masked]<mailto:[email-masked]>>
Sent: 11 February 2022 17:03

From: Carsten Bormann <[email-masked]<mailto:[email-masked]>>

<tp>
If you are referring to

<tp>

Try again.

Tom Petch

Grüße, Carsten

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 14 Feb 2022 10:45:32 +0100

I already pointed to <https://www.w3.org/2001/tag/doc/qnameids>. There
are a number of situations where the ability to resolve namespace
prefixes is required when processing XML content. Yes, in hindsight,
we could have designed things differently, but the ship has sailed.

There are a number of things in YANG/NETCONF that you can't implement
if your XML API does not provide the capability to resolve namespace
prefixes. I guess people deep into YANG/NETCONF all know this and it
is a no issue for them. But then there might be script writers that
just look at examples, never read the specifications and at best use
stackexchange. Not sure whether additional warnings help them, perhaps
a good discussion and answer on stackexchange is practically much more
effective these days. ;-)

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Feb 2022 10:14:48 -0800

On Mon, Feb 14, 2022 at 1:19 AM Jan Lindblad (jlindbla) <[email-masked]>
wrote:

> People (including IETF) have also defined types that use qname:s inside
> YANG strings, which the servers and clients would have to recognize and
> treat properly in order to interoperate well.
>
> module ietf-yang-types {
> ...
>   typedef xpath1.0 {
>     type string;
>     description

Good point.  Not just a server implementation detail I guess.
We had a YANG extension for this before this xpath type came out.
https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-xpath

The server implementation definitely needs to know (early in the
processing) which strings are plain strings
and which are XPath expressions.  Usually it is too late to get the
namespace bindings
after the XML parser is finished.

Maybe a solution for YANG 2.0...
Create a standard algorithm to convert QName and xpath:1.0 strings to a
canonical format,
using the module-name approach defined in RFC 7951.

For now, there is no real problem to solve. Supporting YANG 1.1 requires the
implementation to be aware of XML prefixes in string node content.
Leaf value comparisons involving strings with XML prefixes are not reliable.
(Maybe a whole new can of worms there...)

Andy

> On 14 Feb 2022, at 10:05, Ladislav Lhotka <[email-masked]> wrote:
>
> I looked into XSLT 2.0, sec. 5.1 [1], hoping that we could use it as a
> model, but it became clear to me that we have a bigger problem: equality of
> identityref values isn't properly defined in YANG. We resolved this in YANG
> 1.1 for identityrefs appearing in XPath expressions by adding the functions
> "derived-from" and "derived-from-or-self", but the problem still persists
> e.g. when comparing identityref values serving as list keys (sec. 9.1 in
> RFC 7950 doesn't help here).
>
> Lada
>
> From: netmod <[email-masked]> on behalf of tom petch <
>
> [email-masked]>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Feb 2022 09:34:09 +0100

> using the module-name approach defined in RFC 7951.

This is not so easy, as long as a canonical value must also stay lexically valid in a given representation. The only reasonable (but backwards incompatible) solution seems to be to change the XML encoding of identityref values to be the same as in RFC 7951.

Lada

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 17 Feb 2022 10:02:52 +0000

Hi Tom,

Thanks for flagging this.

I agree that this text is not helpful in understanding the examples (nor is this text present in other YANG module examples), and I will indeed raise this in my ballot.

Regards,
Rob

-----Original Message-----
From: tom petch <[email-masked]> 
Sent: 12 February 2022 12:54
To: Rob Wilton (rwilton) <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] Use XML namespaces in YANG document examples

Tom Petch

>> (I'm also still not sure I've got an answer to my question about using inconsistent prefixes between YANG and the XML example.  What is being demonstrated here?)
>>
> <tp>
> If you are referring to

I'm referring to the question I was trying to ask when I said this :-)

I was answering to a throwaway note that the authors got flak when their XML did not use the defined prefix.  My question was: why do that, then?  Maybe that was not understood because "ianaift" actually *is* the prefix preferred in the YANG module, so my question doesn't make sense.  (I'm not sure what the throwaway referred to.)

<tp>

Try again.

Tom Petch

Grüße, Carsten