- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 1 Oct 2008 16:46:51 +0100
- To: public-xmlsec@w3.org
- Cc: public-xmlsec-comments@w3.org, hoylen <hoylen@hoylen.com>
Forwarding and archiving with permission. -- Thomas Roessler, W3C <tlr@w3.org> Begin forwarded message: > From: hoylen <hoylen@hoylen.com> > Date: 1 October 2008 05:04:23 BST > To: tlr@w3.org > Subject: XML Canonicalization and "xml:" XML namespace declarations > > Thomas, > > I couldn't figure out from the XML Security Working Group's public > Web page > how the public can contact the WG (or if the WG even wants such > input). So > I'm sending this email to you. If there is an appropriate place to > raise > this issue, then please do so; otherwise, you may ignore it. > > > In its maintenance of the XML Canonicalization and Exclusive XML > Canonicalization specifications, could the Working Group please > explicitly > clarify how declarations of the "xml:" XML namespace are to be > handled? > That is, occurrences of xmlns:xml="http://www.w3.org/XML/1998/namespace > ". > > The unique behaviour of the XML namespace makes the interpretation > of the > canonicalization rules ambiguous. The unique behaviour comes from > section > 3 of Namespaces in XML 1.0 (Second Edition) [1] where it says: "It > may, but > need not, be declared, and must not be bound to any other namespace > name." > > > > Consider a source XML document, which we will call S0: > S0: <a><b><c xml:id="C"/></b></a> > > If we wanted the canonicalized form of the document subset /a/b, > there are > four possible forms: > > C0: <b><c xml:id="C"></c></b> > C1: <b><c xmlns:xml="http://www.w3.org/XML/1998/namespace" > xml:id="C"></c></b> > C2: <b xmlns:xml="http://www.w3.org/XML/1998/namespace"><c > xml:id="C"></c></b> > C3: <b xmlns:xml="http://www.w3.org/XML/1998/namespace"><c > xmlns:xml="http://www.w3.org/XML/1998/namespace" xml:id="C"></c></b> > > Canonical XML Version 1.1 implies (through an example) that the > canonical > form of S0 is C0. However, I have seen an implementation use C1 as > the > canonical form -- I think this is incorrect, but cannot point to > anything > in the specification that says it is wrong. > > > > Consider another source XML document, which we will call S4: > S4: <a xmlns:xml="http://www.w3.org/XML/1998/namespace"><b><c > xml:id="C"/></b></a> > > The Canonical XML Version 1.1 Recommendation could mean that the > canonical > form of a/b from S4 is C2. It could also be interpreted as C0. It is > ambiguous how the statement that "it may, but not need, be declared" > is to > be interpreted in the context of canonicalization. > > > > Consider another source XML document, which we will call S1: > S1: <a><b><c xmlns:xml="http://www.w3.org/XML/1998/namespace" > xml:id="C"/></b></a> > > Is the canonical form of /a/b form of S1 represented by C0, C1, C2 > or C3? > > > > > The Canonical XML specification needs to be explicitly clear which > is the > canonical form when declarations of the XML namespace is involved. > > I suggest that a normative rule be explicitly stated that: xmlns:xml > declarations must NOT appear anywhere in the canonical XML. So C0 is > always the canonical form for all the examples mentioned in this > email. > > This should also apply to Exclusive XML Canonicalization too. > > Thanks. > > Hoylen > > > P.S. The above example documents were drawn from a set of 8 possible > combinations. Some of these other documents are useful when > considering the > rules for the behaviour of Exclusive XML Canonicalization. > > <!ENTITY X "xmlns:xml='http://www.w3.org/XML/1998/namespace'"> > > S0: <a ><b ><c xml:id="C"/></b></a> > S1: <a ><b ><c &X; xml:id="C"/></b></a> > S2: <a ><b &X;><c xml:id="C"/></b></a> > S3: <a ><b &X;><c &X; xml:id="C"/></b></a> > S4: <a &X;><b ><c xml:id="C"/></b></a> > S5: <a &X;><b ><c &X; xml:id="C"/></b></a> > S6: <a &X;><b &X;><c xml:id="C"/></b></a> > S7: <a &X;><b &X;><c &X; xml:id="C"/></b></a> > > > [1] <http://www.w3.org/TR/2006/REC-xml-names-20060816/> > -- > hoylen@hoylen.com -- Hoylen Sue > >
Received on Thursday, 2 October 2008 08:58:59 UTC