- From: Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
- Date: Fri, 27 Oct 2006 11:44:43 +0200
- To: Richard Tobin <richard@inf.ed.ac.uk>
- CC: public-xml-core-wg@w3.org
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
Received on Friday, 27 October 2006 10:24:18 UTC