Re: Erratum to XML 1.0 spec to allow xml:lang=""

On Wednesday 18 September 2002 04:22 pm, Paul Grosso wrote:
> Speaking only for myself, I'd say you're right about xml:space.

Ok.

> As far as xml:base, I'm not sure what it is you want to accomplish.
> There is always a base URI, so it's not like you'd want to "turn off"
> the base URI.  If you want to say that there is no overriding base URI,
> I'd think that xml:base="" would do that--it would set the base URI to
> that of the current resource which is what the base URI would be if there
> were no xml:base in it.
>
> On the other hand, if what you're trying to do is preserve the base URI
> for the fragment even after it becomes a subtree of the receiving
> document, it seems you could set the xml:base attribute explicitly to the
> base URI of the pre-inserted fragment.  Without that explicit information
> being available, I can't see how any value of xml:base could ever be used
> to imply it.

Yes, and this is what we say in the spec, the trick there is a schema might 
not permit the addition of xml:base attributes in the root of the fragment. 
So we say "beware".

The new text on the xml:lang is below (I didn't provide an actual formal 
reference to that document, but a link to the erratum.... (?) )

   http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/
   $Revision: 1.242 $ on $Date: 2002/09/20 14:22:46 $ GMT by

   ...
   where Bongo's href is subsequently interpreted as
   "http://example.org/example.xml". If this is not the correct URI,
   Bongo should have been serialized with its own xml:base attribute. The
   recommendation that xmlns="" be emitted to divorce the default
   namespace of the fragment from the context into which it is being
   inserted can not be made for the attributes xml:base, and xml:space.
   (Error 41 of the XML 1.0 Second Edition Specification Errata clarifies
   that an empty string value of the attribute xml:lang is considered as
   if, "there is no language information available, just as if xml:lang
   had not been specified".)

   The interpretation of an empty value for these attributes is undefined
   or maintains the contextual value. Consequently, applications SHOULD
   ensure (1) fragments that are to be encrypted are not dependent on XML
   attributes, or (2) if they are dependent and the resulting document is
   intended to be valid [XML], the fragment's definition permits the
   presence of the attributes and that they have non-empty values.

Received on Friday, 20 September 2002 10:25:49 UTC