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

Tim Bray <tbray@textuality.com> Thu, 03 February 2022 21:53 UTC

Return-Path: <tbray@textuality.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F793A0E8C for <netmod@ietfa.amsl.com>; Thu, 3 Feb 2022 13:53:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc7VK-_q7NZe for <netmod@ietfa.amsl.com>; Thu, 3 Feb 2022 13:53:44 -0800 (PST)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8E73A0E6B for <netmod@ietf.org>; Thu, 3 Feb 2022 13:53:43 -0800 (PST)
Received: by mail-lj1-x231.google.com with SMTP id t14so5869692ljh.8 for <netmod@ietf.org>; Thu, 03 Feb 2022 13:53:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kXQziEUhKgu9tcK3cevHeq8N+T0pgz2S+3I/8n+/0II=; b=HDGQmt5qD6n17waY/CpBeuFBFluXq5XCp3uGz6JuvvnX/DAxWdhVOkfEO9HA0TlnTk Tw/BTjqHhn+C+fJ2tXcmbUBDHlas2Y+Gx8zuHyS7G3M2rKp3w12KHRQT0cGZvrZXXLuD K+BG2u/7VRDvM/Tej2KOapXGyspH5ZQhDSk3BY0RaGGC7MOuTxFw5UENfAxbHxndkuwD zsuCuK0AqdJxM12g3z1HPrLSe6OSXdtyMbbL3DBExR/GK6lB4lwEoF9CzbuM7BYmTFxv YIrfeWVhkf3edJnAR3fLKAB9W9egzqyeFCfhKgsoPiMP3JorN0LKuoK1iD7OZ/LvTHzX hJnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kXQziEUhKgu9tcK3cevHeq8N+T0pgz2S+3I/8n+/0II=; b=zLN5Kc13pkpeIRj2OW+uoug1dBM8/AtHJE16U5AUsE+Po9X+NnGuC2mM8Qp4CSUc0R ErYsYWPHkTsZeSE8awD2UkWbNYy1SZBJeCfRtnSxO7DoNuwWFVotD74qp03q8Pb3IrAe lMcuDs+WgBE74tT2ucbWQqeFaFSaZo5tKfopKJ9te54lB31o400lsh6fzG/84hM2xrM0 xMLkfB0Wp1NKhiviH/b+1dNGllN+A2lHsXdy5yw4aa72aM3Ms8OVO5EnVyT/2fJv8Uzu 8YC9rWPLaGYk1Uyj0yAPgWzBwnOLO9sdIA3kRufwGzkrgXHfNWHHIrxrQhuOLTcagmcn fRsw==
X-Gm-Message-State: AOAM533r9R9edrEwnT0UELEsDAuKAT5dJX3p4IkPqQ2vOZ/oUUfhLnMV 3eh5hlaqVT025vh3+b8Q9LoshjdA3LB2p3DGbM1psw==
X-Google-Smtp-Source: ABdhPJyeIpMiaMdlLbpolpFlGx7N/eeuDmjezGLVLKHB45j4LMDyLjpRlGDTbFqfbrVFmnCyMgIZi/45zaqy0tqAu48=
X-Received: by 2002:a2e:3305:: with SMTP id d5mr2749ljc.358.1643925220745; Thu, 03 Feb 2022 13:53:40 -0800 (PST)
MIME-Version: 1.0
References: <B6F5C201-A42B-47AB-9518-886C97EBA931@gmx.com> <AM7PR07MB624865498F51F41EFD26D723A0289@AM7PR07MB6248.eurprd07.prod.outlook.com> <CABCOCHSM0MdXwY5AKkSXvvxDqf_CDX6SamZtMJotrn4R8FQ7Bw@mail.gmail.com> <CAHBU6iucqMiyVdZncfTHdO=y7dqz=4i0UTqMRa+BBSp=1sTpSw@mail.gmail.com> <CABCOCHRLmi2mQoeEQcYS5b8=0wKUxGY7ntRhqSGLXje=nctgdA@mail.gmail.com> <CAHBU6ivX+j4aY_f_ftQo2Uwvr-u+Y-qebY=jsk0mUDNpHVRi3g@mail.gmail.com> <CABCOCHQ6MqU8kzfnd4GXddndhrvKNPDiDhBPDDNOgiHR_jpDxg@mail.gmail.com>
In-Reply-To: <CABCOCHQ6MqU8kzfnd4GXddndhrvKNPDiDhBPDDNOgiHR_jpDxg@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
Date: Thu, 03 Feb 2022 13:53:29 -0800
Message-ID: <CAHBU6iv_zC-crCzxa7r-b1xraBBcZ7PEsyWQEuS-XRx_ddY1Ow@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
Cc: tom petch <ietfc@btconnect.com>, "ianfarrer@gmx.com" <ianfarrer@gmx.com>, "netmod@ietf.org" <netmod@ietf.org>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>, "drafts-expert-review@iana.org" <drafts-expert-review@iana.org>
Content-Type: multipart/alternative; boundary="000000000000d204ea05d7242ac9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/HKr9I_7ex-UNI-YrLOCdFlI4KwM>
Subject: Re: [netmod] Use XML namespaces in YANG document examples
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2022 21:53:50 -0000

On Thu, Feb 3, 2022 at 10:04 AM Andy Bierman <andy@yumaworks.com> wrote:

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

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.



>
>
> Andy
>
>
>
> On Thu, Feb 3, 2022 at 9:54 AM Tim Bray <tbray@textuality.com> wrote:
>
>> On Thu, Feb 3, 2022 at 9:46 AM Andy Bierman <andy@yumaworks.com> wrote:
>>
>>>
>>> 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.
>>
>>
>>
>>
>>
>>>
>>>
>>> Andy
>>>
>>>
>>>> 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)
>>>> ]
>>>>
>>>>
>>>> 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 <andy@yumaworks.com> 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
>>>>>
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>> On Thu, Feb 3, 2022 at 3:53 AM tom petch <ietfc@btconnect.com> wrote:
>>>>>
>>>>>> From: netmod <netmod-bounces@ietf.org> on behalf of ianfarrer@gmx.com
>>>>>> <ianfarrer@gmx.com>
>>>>>> Sent: 03 February 2022 09:37
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> <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
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>
>>>>>