There's been resolution on the issue about getElementById() on
XML-based DOM nodes imported/adopted/cloned. They don't carry over. See....
http://issues.apache.org/jira/browse/XERCESJ-1022
However, note that this does not apply to HTML-based DOM's, since
they literally traverse the document for elements with "id"
attributes with a specified value. I had removed this from the XHTML
DOM because I didn't think it was required there. Because XHTML is
XML with a valid DTD that defines certain attributes as of type "ID",
the parser automatically stores references of elements with these
attributes in its internal Id map (and, in fact, I do the same thing
for the HTML DOM using a NekoHTML Filter to optimize things there,
but with fallback to non-optimized behavior if that fails). This is
great for optimized getElementById() lookup, but not so good if the
element doesn't happen to be in the Id map, as happens when nodes are
imported/adopted/cloned.
Because XHTML is a variant of HTML and retains the HTML DOM's
behavior in most other ways, it should retain the fallback
getElementById() behavior. But please don't expect this in
non-HTML-based DOMs as there is no way to provide fallback behavior
unless it is your own DOM implementation and you write the
proprietary fallback code. For standard XML-based DOM's, your
choices are to call Document.normalizeDocument() with Validation
enabled (or Element.setIdAttribute() if you have a handle on a
particular imported/adopted/cloned element and want to register that
element into the Id map) or serialize and reparse.
As I mentioned in a previous response, I checked in the change to add
back the getElementById() fallback behavior in the XHTML DOM. I'll
try to get builds out this weekend.
Jake
At 11:35 AM 1/26/2007, you wrote:
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
--
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
| 