Re: [xmlc] 2.3beta getElementById() behavior

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).

I was under the impression that all this getElementById() requirement was being forced into XML by HTML.  I didn't realize that XML had this concept of "attributes can have an id that isn't necessarily an 'id' attribute".  In that case, standardizing it to one attribute makes sense.

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.

Erik

--
You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx mailing list.
To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws