On Jan 26, 2007, at 5:42 PM, Jacob Kjome wrote:
2. Keep in mind that just because getElementById() ends in "Id", doesn't imply
anything about the attribute name. The fact that the HTML DOM chose a specific
attribute, "id", to represent an attribute of type ID says nothing about any
other markup dialect.
Wow. That wasn't at all clear to me before.
It seems like it wouldn't be too difficult for
XHTMLElementImpl.cloneNode() and XHTMLElementImpl.importNode() to
access its XHTMLDocument's id map. The implementations of these
methods in XMLElementImpl wouldn't care about maintaining maps of any
attributes.
Well, right now, all the ID magic takes place in the core DOM implementation of
Xerces. It's the fallback recursion that is localized to HTMLDocumentImpl,
LazyHTMLDocumentImpl, and XHTMLBaseDocumentImpl. Localizing the core ID magic
to HTMLDocumentImpl would be totally pointless because HTML documents aren't
validated and, therefore, never know anything about the ID'ness of the "id"
attribute, other than simply assuming it is the defacto attribute treated as an
attribute of type "ID". It would also make it difficult for various DOM
implementations to share logic and DOM3's functionality of defining certain
attributes as of type ID wouldn't exist.
It all seems pretty straightforward to me, but I'm no expert in XML
parsing or DTDs, so I'm sure there are more complicated issues that
I'm missing. I'd be against a standard "xml:id" attribute.
I'm not clear why? There are already other magic XML attributes such as
"xml:space". "xml:id" would clear up the whole "what is an Id in XML" debate
and allow for getElementById() to work for well-formed, but not necessarily
validated, XML documents. Thus, no requirement for a DTD to define it and
you'd have attributes of type ID even when using Schema instead of DTD (or no
DTD/Schema at all).
The whole issue is pretty disgusting. XML is such a horribly bloated data format. A brace-based format like JSON or Lisp code would be at least as human readable, just as easy to parse, and much more compact. I see no reason why you couldn't write the equivalent of a DTD for JSON.
Standards are such a pain. At least I work for a small and agile enough company that I've been able to break out of the prison that is JSP/servlets and can use something as innovative as XMLC.
Thanks for all the info about this issue. It's been interesting.
