- From: Joseph Reagle <reagle@w3.org>
- Date: Wed, 24 Apr 2002 14:39:45 -0400
- To: Martin Duerst <duerst@w3.org>, Misha.Wolf@reuters.com, Philippe Le Hegaret <plh@w3.org>, jmarsh@microsoft.com
- Cc: w3c-i18n-wg@w3.org, w3c-ietf-xmldsig@w3.org, xml-dist-app@w3.org, xml-encryption@w3.org
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