- From: Elliotte Harold <elharo@metalab.unc.edu>
- Date: Fri, 22 Apr 2005 18:18:36 -0400
- To: Chris Lilley <chris@w3.org>
- CC: "Bassetti, Ann" <ann.bassetti@boeing.com>, public-xml-id@w3.org, "Bugbee, Larry" <larry.bugbee@boeing.com>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, Liam Quin <liam@w3.org>, Bert Bos <bert@w3.org>, "Reid, Travis S" <travis.s.reid@boeing.com>, "Gerstmann, Jerry P" <jerry.p.gerstmann@boeing.com>, "Meadows, Joe" <joe.meadows@nobs.ca.boeing.com>
Chris Lilley wrote: > It seemed therefore that you were arguing that xml:* should mean > inherited. Now you seem to be saying that all future xml* should ot be > xml:* whether inherited or not. I'm saying that the assumption is already out there that xml:* attributes are inherited. Therefore putting any non-inheritable attribute into xml:* is wrong and will cause problems. I am also arguing that the xml:* mechanism is fundamentally broken and should never be used again, inherited or otherwise. In other words there are two good reasons not to use xml:* for non-inherited attributes, and one good reason not to use xml:* for inherited attributes. I see no good reasons to use xml: for any newly defined attributes or elements. > I think you overstate the case. xml:base added some badly needed > capabilities to the language. Which arguably should have been there from > the beginning (much more useful than things that did make it in, such as > DTD syntax, external parsed entities, notations, etc). xml:id similarly > should have been there from the beginning, as soon as fetching the > external DTD subset was made optional rather than mandatory. I have no objection to the general functionality of xml:base. However making it an xml:* attribute instead of xmlbase has caused problems it would not otherwise have. > Without a time machine, the easiest way to fix that now is to add them, > now. No. The easiest way to fix the problem of identity determination in the absence of DTDs is to define this with xmlid. xml:id is not the easiest or the best solution here. That we failed to recognize the easiest, cleanest, least kludgey solution for past problems is no excuse for knowingly choosing the wrong solution for the current problem. > Moving away from namespaces - but only for the xml namespace - just > sounds like a short term kink to me, one that will be viewed in > retrospect as "ah yes, namespaces were unfashionable 2004-2006 so we > have this wart where its not actually in a namespace ..." The wart is xml:. It does not behave like other namespaces. It cannot be remapped to a different prefix. It requires special handling from libraries. It's time to apply some Compound-W to this wart. Remember: far more attributes are not in namespaces than are. There is nothing the least bit warty about an attribute that's in no namespace. It is simple. It's clean. It works. This fetish for namespaces must end. Where namespaces add no value and indeed cause active problems, they should not be used. -- Elliotte Rusty Harold elharo@metalab.unc.edu XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
Received on Friday, 22 April 2005 22:18:43 UTC