Re: FW: W3C XML ID ambiguity

On Saturday, April 23, 2005, 12:18:36 AM, Elliotte wrote:

EH> The wart is xml:. It does not behave like other namespaces. It
EH> cannot be remapped to a different prefix. It requires special
EH> handling from libraries. It's time to apply some Compound-W to this
EH> wart.

I agree that the fact that it does not behave like other namespaces is
problematic. I would have preferred it to have bee remappable and to fix
the URI but not the prefix; on the other hand, having a predeclared
prefix is a win too.

I don't hear you calling for rescinding xml:space, xml:base and so the
magic predeclared not remappable namespace code still needs to be in the
parser, right? So re-using it does not seem to cause additional burden.

However, that is already in XML and its too late to change XML in tha
area (the chances of an XML 1.2 that is like 1.0/1.1 except that the xml
namespace has to be explicitly declared and can be mapped to any prefix,
and xml:space is called xml-inheritable-space, and xml:id is called
xml-noninheritable-id, and so forth do not seem that high).

EH> Remember: far more attributes are not in namespaces than are. There is
EH> nothing the least bit warty about an attribute that's in no namespace.

- if its reserved, which is indeed the case here. For most attributes,
not reserved, then whether they are in a namespace or not *is* a big
deal when you meet them on unknown elements.

EH> It is simple. It's clean. It works. This fetish for namespaces must
EH> end. Where namespaces add no value and indeed cause active problems,
EH> they should not be used.





-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

Received on Friday, 22 April 2005 22:33:31 UTC