- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Tue, 08 Aug 2006 16:52:48 -0400
- To: Robin Berjon <robin.berjon@expway.fr>
- CC: public-appformats@w3.org
Robin Berjon wrote: > On Aug 03, 2006, at 23:41, Ian Hickson wrote: >> It has come to my attention that not everybody thought that the xml:id >> discussion was resovled. To recap, the conclusion was that xml:id can >> be used with XBL2 if desired, and that in addition, a simple "id" >> attribute is to be included for consistency with HTML. If this doesn't >> cater for your use case, please don't hesitate to reply to this e-mail >> explaining your use case and how this solution does not satisfy it. > > I don't think that this solution exemplifies good, quality design and > I've already made my objections and use cases clear, but in the > interest of not wasting my vacation time talking with someone > incapable of cool-headed discussions using arguments grounded in > reality rather than theology, or for that matter basic respect for > others and their opinions, I don't see the point of discussing it > further. Please explain where the dual use of |xml:id| and |id| is undesirable. Clearly, if the author is the source of the XBL code, they will use whatever is their preference, so I would think that server-side scripting is not an issue. If the author is not the source of the XBL, what is the scenario where said author would be manipulating the XBL? Out of curiosity, why can't namespaces simply inherit attributes from the "xml" namespace? That way I could use this... | <[ns:]element id="..." lang="..." base="..." /> ...instead of this: | <[ns:]element xml:id="..." xml:lang="..." xml:base="..." /> XML-based languages could then simply override to add functionality or implement the attribute in a different manner. The original attribute in the "xml" namespace could still be accessed using the "xml:" prefix. (Please excuse any general ignorance regarding XML. I fully admit that I may not know what I'm talking about.)
Received on Tuesday, 8 August 2006 20:52:57 UTC