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

[Ladislav Lhotka <[e-mail]>]

Andy Bierman <[e-mail]> writes:

> On Sat, Feb 12, 2022 at 6:57 AM Jürgen Schönwälder <
> [e-mail]> 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 <[e-mail]> on behalf of tom petch <
>> [e-mail]>
>> > Sent: 11 February 2022 17:03
>> >
>> > From: Carsten Bormann <[e-mail]>
>> > 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/netmod
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>> --
>> Jürgen Schönwälder              Jacobs University Bremen gGmbH
>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   [phone]         <https://www.jacobs-university.de/>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

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