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

Mahesh Jethanandani <mjethanandani@gmail.com> Thu, 03 February 2022 17:43 UTC

Return-Path: <mjethanandani@gmail.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 AFA923A11EF; Thu, 3 Feb 2022 09:43:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 h2CilmQbULET; Thu, 3 Feb 2022 09:43:54 -0800 (PST)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 E82673A11EC; Thu, 3 Feb 2022 09:43:53 -0800 (PST)
Received: by mail-oi1-x235.google.com with SMTP id m9so5137265oia.12; Thu, 03 Feb 2022 09:43:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jRvqREUpFglyCHmk+YNZGzh7o+k14WSqYSbKmmcW3vM=; b=bjju/2bvVQc2KCHGGbnWyNKuWgk+Vftvmc1hu472g/+HP+/wCzd2eWju7SO5k7nrmu fwnjqH2E56TeM7Fa+9zFTMeIJR5dRd/h69r/aGA3gO0TkveCYwcY7MHmdRPJxM1Fx3ry 8bRMu0sXQ+IhAaA0q+4RcN/ezbgwWsUOqYujYpJS8JA1KZs8NDd20h2w4uwYHVqqR1FY 4mwb2snCPd9Ghy6P2eEQVSUgNw1w9LeIHyjohXav2MqmZvFRvsV12qf7vdF46xYMoTKe 7SLKCIa+ApTmDd/3pNgVW7fTCVjxJBcEuSJKa49dECQYacXoBDRcxIo9YxkHh+EJpCye 2kaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jRvqREUpFglyCHmk+YNZGzh7o+k14WSqYSbKmmcW3vM=; b=wzQoSFLCrEq0fcfKuHzZf1XgO8BCtSBykTISOyf6ZFlZqFaYJhiqMuLvqpPWrtUFz2 /bFZGr9eqZT8r/4/Mm+wiFqU9GXr5eILqFsf+vSkxvUS1lr3bEEBDCAXXaRKhb7b9MLe 2Iqj7ca75dEjHN7affzEz3kLgb7qgood3WpqCNY5/8DwAMPETBtYvl4lGH8dzOgUZpPk b2Cbe2Dqo1Q0w1wMXRBdBdFZqMIzYeKF7v73gjJXoTNOfCpIcJ/v6GJh5k9Cl14wIK6a Gey3L2PIXDyuxaQa3feSEJs+kmuzwFuEuepwoOpoGjPAKTtuPiJ6B6FMylmnFilcu/oa 10TQ==
X-Gm-Message-State: AOAM531q29XIIA552I03BT+Q8OT/t49uyFkNsOm2lLsJn4aTGmxBdkwn spDXxZ0FEzXhyZoLEUtsB6bn7F8OKd8=
X-Google-Smtp-Source: ABdhPJwf4knEkhn0cxYl3Cf3g1mznc8CRz1wUhsW4pyvA9ET7rRT1D69iDBwj5AOixj4UlybUUkA0A==
X-Received: by 2002:a05:6808:1822:: with SMTP id bh34mr8239395oib.209.1643910231653; Thu, 03 Feb 2022 09:43:51 -0800 (PST)
Received: from smtpclient.apple (adsl-70-234-233-187.dsl.rcsntx.sbcglobal.net. [70.234.233.187]) by smtp.gmail.com with ESMTPSA id bl6sm7836871oib.38.2022.02.03.09.43.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Feb 2022 09:43:50 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <C2FC4904-F0BA-4992-9F50-090313CCD528@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D917988F-38ED-4435-BFD1-6B9BA458BF41"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Thu, 03 Feb 2022 09:43:49 -0800
In-Reply-To: <CAHBU6iucqMiyVdZncfTHdO=y7dqz=4i0UTqMRa+BBSp=1sTpSw@mail.gmail.com>
Cc: Andy Bierman <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>, "drafts-expert-review@iana.org" <drafts-expert-review@iana.org>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Tim Bray <tbray@textuality.com>
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>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/edULMjOF3vbv46Lzcyb0nUCvZ1Y>
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 17:43:59 -0000

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 <tbray@textuality.com> 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:
>> 
>>  <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)
> ]
> 
> [mj] It would work if the type field used the prefix that was defined, i.e.
> <type>foo:ethernetCsmacd</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):
> 
> [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 <andy@yumaworks.com <mailto: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 <https://www.w3.org/TR/xml-names/#ns-qualnames>
> 
> 
> Andy
> 
> 
> On Thu, Feb 3, 2022 at 3:53 AM tom petch <ietfc@btconnect.com <mailto:ietfc@btconnect.com>> wrote:
> From: netmod <netmod-bounces@ietf.org <mailto:netmod-bounces@ietf.org>> on behalf of ianfarrer@gmx.com <mailto:ianfarrer@gmx.com> <ianfarrer@gmx.com <mailto: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/ <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 <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanandani@gmail.com