Re: Minutes for XML Core WG telcon of 2007 February 14

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.