- From: Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
- Date: Mon, 19 Feb 2007 17:58:43 +0100
- To: "Grosso, Paul" <pgrosso@ptc.com>, public-xml-core-wg@w3.org
- Message-ID: <45D9D743.8040409@iaik.tugraz.at>
Grosso, Paul wrote: >> 3. C14N [...] > Jose forwarded a message from Philippe: > http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Feb/0008 > > What is the relationship between C14N 1.1 and XML 1.1? > > We see no reason that C14N 1.1 couldn't be used with XML 1.1. > Philippe would like us to make this clear in the C14N 1.1 spec. > I mostly agree - with some exceptions. > Namespaces 1.1 does allow the undeclaring of a namespace prefix > which might cause problems for C14N. Well that depends on how XPath 1.0 would treat that. > But then we decided there > might already be problems with C14N and NS 1.0 (not preserving > prefixes in some cases--what JohnC calls qname-correctness). > I'm not sure this is a problem, as I'm not aware of a requirement in C14n to return well formed namespace conformant XML under all circumstances (see. http://www.w3.org/TR/xml-exc-c14n/#sec-EsotericNodesets). Although such a requirement may be desirable for future canonicalization specifications. > JohnC suggests: If a namespace is declared in the input, then > it must be declared in the output. > That is what I would consider the usual case. (Note: In the XPath data model all elements bear their namespace declarations in scope, as if they where distributed to all elements along the descendant-or-self axis). The exception however is if all the namespace nodes (NsDecls) along an element's (E) ancestor axis declaring E's namespace (N) are NOT in the input nodeset. The binary output then created by C14n would violate the namespace constraint: "Prefix Declared" (see. http://www.w3.org/TR/REC-xml-names/#nsc-NSDeclared), but may still be valid in some surrounding context. My interpretation up to now always was that one would have to assume this output was created intentionally (which conforms to the current c14n specification) . Exclusive C14n in contrast treats the namespace nodes almost as suggested by JohnC (see http://www.w3.org/TR/xml-exc-c14n/#sec-Specification step 3. condition 3.) with the exception (http://www.w3.org/TR/xml-exc-c14n/#def-visibly-utilizes) that namespaces needed by something else than elements or attributes (XPath expressions and the like) would have to be included into the "InclusiveNamespaces PrefixList". The alternative view would be to say a fixup is also necessary in plain C14n to prevent the creation of output violating the namespace constraint: "Prefix Declared". > John points out that it's not clear how you generate an xpath 1.0 > model for an XML 1.1 document. > True, it does not refer XML 1.1 at all. The second bullet point in section 5.4 "Namespace Nodes" (see http://www.w3.org/TR/xpath#namespace-nodes) would need to be modified in a similar way to the third bullet point. I think changing the text in second bullet point from """ * for every attribute on an ancestor element whose name starts |xmlns:| unless the element itself or a nearer ancestor redeclares the prefix; """ to """ * for every first attribute (nearest per prefix) on an ancestor element whose name starts with |xmlns:| and the value of the attribute is non-empty unless the element itself redeclares the prefix with a non-empty value; Note: empty values appear in XML 1.1 to undeclare a namespace prefix. """ could be possible. However such a change would require further changes to the c14n specifications to maintain the "undeclaring" of prefixes. An alternative approach would be to treat xmlns:prefix="" just like normal redeclarations that simply "overwrite" a prefix with a "non-namespace" in which case I think the c14n specifications could remain mostly untouched. > ACTION to JohnC: Send email to the list summarizing the issue > and your suggested solution. > If I can be of any help please let me know. regards Konrad P.S.: Please accept my late regrets as I had caught a cold last week and stayed in bed a few days.
Received on Monday, 19 February 2007 16:58:58 UTC