LGTM. On Mon, Feb 7, 2022 at 11:40 AM <ianfar...@gmx.com> wrote:
> 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 <mbj+i...@4668.se> wrote: > > Jernej Tuljak <jernej.tul...@mg-soft.si> wrote: > > > > On 04/02/2022 08:18, Martin Björklund wrote: > > Tim Bray <tb...@textuality.com> wrote: > > On Thu, Feb 3, 2022 at 10:21 AM Martin Björklund <mbj+i...@4668.se> > wrote: > > 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). > > 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). > > > 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. > > > 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. > > 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). > > > I guess I wonder if this is b/c the specification says so, or that > some implementations choose to do so. > > > /martin > > > > > Jernej > > > > /martin > > > 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. > > Agreed. > > > > > /martin > > > > > > > > > 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 <a...@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 <ie...@btconnect.com> > > wrote: > > From: netmod <netmod-boun...@ietf.org> on behalf of > > ianfar...@gmx.com < > > ianfar...@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 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
