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 protected]<mailto:[email protected]>> wrote:
Andy Bierman <[email protected]<mailto:[email protected]>> writes:
On Sat, Feb 12, 2022 at 6:57 AM Jürgen Schönwälder <
[email protected]<mailto:[email protected]>>
wrote:
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.
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 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
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
On Sat, Feb 12, 2022 at 12:54:18PM +0000, tom petch wrote:
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 protected]<mailto:[email protected]>> on
behalf of tom petch <
[email protected]<mailto:[email protected]>>
Sent: 11 February 2022 17:03
From: Carsten Bormann <[email protected]<mailto:[email protected]>>
Sent: 11 February 2022 08:21
(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
" 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.)
<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
_______________________________________________
netmod mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
--
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/>
_______________________________________________
netmod mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
