Re: XML Core WG Status and Open Actions as of 2006 October 16

Hi Richard,

Richard Tobin wrote:
> [...]
>> * How about changing the last sentence in section 5.2 "Granularity of 
>> base URI information" to
>> """
>> The base URI of an element bearing an |xml:base| attribute having a 
>> value that is not a valid XML Resource Identifier is undefined and SHOULD
>> cause an error on URI resolution.
>> """
>>     
>
> The sentence comes from an erratum agreed in 2004.  Changing it in the
> way you suggest would amount to a new erratum.  I don't recall why
> we decided it was application-dependent - does anyone?
>   
I see, I didn't know that.
However I personally prefer a uniform behavior over implementation 
dependency,
but I do not have a very strong opinion about that, so either way is fine.

>> * May I further suggest to add the following sentence to section 5.4 
>> "Interpretation of same-document references".
>> """
>> Hence, |xml:base=""| or |xml:base="#fragment"| do not have any effect 
>> and SHOULD not be used.
>> """
>>     
>
> It seems a bit strange to say the people SHOULD NOT use a value just
> because it's useless.  And xml:base="foo" is just as useless.  But it
> might be a good idea to add a note that some implementations implement
> this incorrectly, so it should (lower-case) be avoided.
>   
The intention was to NOT RECOMMENDED xml:base aware applications to use 
of xml:base="", xml:base="#fragment", xml:base="foo" or 
xml:base="bar/../" and the like becuase their interpretation - as turned 
out in this WG (please recall the discussions about xml:base="" 
referring to the document root vs. beeing a noop) - is not quite 
straight forward.

So why shouldn't we discourage something that is useless and complicated?

Further such values are currently not removed by canonicalization as we 
decided to touch xml:base only iff a fix-up is necessary. Hence 
document's containing such xml:base attributes are logically equivalent 
to documents not containing them.
Together with the reason you provided I'd still advocate for NOT 
RECOMMENDING their use, which I think is appropriate after reading 
section 4. in RFC 2119 again.

Again I do not have a very strong opinion about this as these are corner 
cases, and a note will quite likely help as well.
Nevertheless I'd appreciate to have the issue handled properly by either 
discouraging the use of those values use or to have them removed by 
C14N1.1 .

Konrad