Re: Fwd: Moving exc-c14n forward: your response is needed!

On Sunday 21 April 2002 20:29, Martin Duerst wrote:
> There is one specific problem with xml:lang, which is the following:
>
> If the SVG document to be included has no language information, it
> is impossible to note that in the top SVG element or just outside.
> We had some preliminary discussion on how to fix this problem; the
> proposal that has received most support in the I18N WG/IG is to use
> xml:lang="".

That sounds reasonable. An additional problem with these attributes is that 
if one wants to counter a declaration made by an ancestor/envelope, one 
might not even be able to. Are xml:foo attribute even *permitted* in our 
example of SVG? Yes, but what of other applications? We considered this in 
the schema for the root EncryptedKey and EncryptedData structures [1] and 
there wasn't any support to inlude these in the root element, only in 
EncryptionProperties [2]. I wonder how many of our XML applications permit this? 
(I know signature and xml encryption don't.) If we expect to be 
de/composing chunks of XML, should all of our applications support these 
elements in their schema?

[0]http://www.w3.org/TR/SVG/struct.html#StdAttrs
[1]http://lists.w3.org/Archives/Public/xml-encryption/2002Jan/0109
[2]http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/Overview#sec-EncryptionProperties

> In some specific cases, there is a similar problem with namespaces.
> For xml:space, there should not be any such problem, because there
> is a default, which can be made explicit. For xml:base, I don't know
> if there is such a problem or not. I.e. the question is whether
> xml:base="" means 'the current document is the base' or it means
> 'don't change the base you have', or it is undefined.

Jonathan has mentioned that it means "don't change the base you have." This 
could be problematic in that if you incorportate one document into another, 
a semantic difference is introduced that's not possible to remedy.

If I had the document

<svg xml:base="">
  <someElement href="foo.xml"/>
</svg>

and I then put this in a soap envelope.

<soap:envelope xml:base="http://example.org/foo/">
  <soap:body>
    <svg xml:base="">
      <someElement href="foo.xml"/>
    </svg>
  </soap:body>
<soap:envelope>

The SVG won't work properly when it's in the SOAP envelope, but one might 
argue that's to be expected. But what happens when you detach it? That's 
hard for me to say, I think it depends which specs you deal with. Since the 
xml:base specification says the base URI is the base URI of the parent, and 
Jonathan has confirmed that the base URI of a parent element with "" is the 
one already in affect, then if the Infoset reflects that the serialization 
of the "then detached" svg InfoSet might be:

    <svg xml:base="http://example.org/foo/"">
      <someElement href="foo.xml"/>
    </svg>

And of course, the Infoset document warns that things may get ugly with 
"synthetic infosets." [2] 

In exc/c14n we're XPath based, so we just see it as an attribute and would 
emit <svg xml:base=""> .

[1] http://www.w3.org/TR/xmlbase/#granularity
The base URI of an element is:
1. the base URI specified by an xml:base attribute on the element, if one 
exists, otherwise
2. the base URI of the element's parent element within the document or 
external entity, if one exists, otherwise
3. the base URI of the document entity or external entity containing the 
element.

[2] http://www.w3.org/TR/xml-infoset/#intro.synthetic
 This may not be true of an information set constructed by other means; in 
such a case there will be no XML document corresponding to the information 
set, and to serialize it will require resolution of the inconsistencies 
(for example, by outputting namespace declarations that correspond to the 
namespaces in scope). 


> I don't think you should cite XML-Schema, but XML-Namespaces
> (http://www.w3.org/TR/REC-xml-names/#NT-QName).

Ok fixed.


> I'm not very happy here; this can be read as "it's okay to remove
> xml:lang". I think the explanation that XML-C14N and exclusive
> canonicalization provide two extremes, and the application
> designer has to chose the right mix, would be better.

I don't think I share your reading, but I've tweaked it for clarity, I hope 
this addresses your concern: "implementations of this specification only 
render attributes from the "xml" namespace (e.g., xml:lang, xml:space, and 
xml:base) when they are are in the subset being serialized"

Received on Wednesday, 24 April 2002 14:39:56 UTC