Re: [xmlc] 2.3beta getElementById() behavior: msg#00023 java.enhydra.xmlc

Ok, I see. You are using dom="xhtml". And the reason it used to work is that
as of XMLC-2.2.11, the XHTML DOM no longer uses the fallback that the HTML DOM
uses for looking up ID's. Previously, it did the same thing as the HTML DOM
and recursed the document looking for an "id" attribute with the value
specified. However, because the XHTML DOM actually validates the markup,
Xerces uses the DTD definitions of the "id" attribute to register these
attributes as being of type ID and, therefore, enabling optimized
getElementById() lookup for elements with these attributes defined. The
fallback mechanism that the HTML DOM (both Xerces HTMLDocumentImpl and
LazyHTMLDocumentImpl) uses is there because, in most cases, the parser won't
register "id" attributes as of type "ID". XMLC's HTML parser actually uses a
little trick to set these at parse time, allowing for the optimized lookup even
though no DTD validation is performed.

Now, the issue seems to be that importNode()/adoptNode() fails to carry over the
fact that the source document registered these Ids. Therefore, when using the
XHTML DOM, which provides no recursion fallback, the lookup with simply fail.
If you use the HTML DOM, which has the recursion fallback, it should succeed.

So, there's 2 issues here:

1. Should it be expected that importNode()/adoptNode() register attributes that
were of type "ID" in the source document with the destination document? I've
asked this question on the Xerces user list and am awaiting a response.

2. No matter the outcome of #1, should the XHTML DOM provide the same fallback
mechanism that the HTML DOM has, allowing lookup to succeed, albeit with
decreased performance than lookups of Ids that were originally in the
destination document at parse time?

BTW, the XHTML DOM implements the HTML DOM interfaces. I suggest you use those
interfaces rather than the XHTML interfaces. It will make you code more
generic.

Jake

Quoting Erik Rasmussen <rasmussenerik@xxxxxxxxx>:

> You were correct. Here are the results:
>
> 2.3-beta: FAILS
> 2.2.13: FAILS
> 2.2.12: FAILS
> 2.2.11: FAILS
> 2.2.10: WORKS!
> 2.2.9: WORKS!
> 2.2.8.1: WORKS!
>
> Where:
> FAILS --> page.getElementById("importedNode") == null
> WORKS --> page.getElementById("importedNode") == the proper node
>
> I went so far back in time because it didn't occur to me until I got
> all the way back to 2.2.8.1 that the error that started in 2.2.10
> (myPageHTMLImpl.syncWithDocument() was throwing "Node must be a
> document node") was because I had to be regenerating the interfaces
> and impls for every version.
>
> I will leave this with you now. Unfortunately, what this bug breaks
> is more important to me than my incredibly elegant 2.3 dynamic
> document loading hack, so I'm going to roll back to 2.2.10 until you
> can get this fixed.
>
> In case it helps, here's my options.xmlc:
> ----
> <?xml version='1.0'?>
> <!DOCTYPE xmlc PUBLIC " -//ENHYDRA//DTD XMLC 1.1//EN"
> "http://www.enhydra.org/xml/xmlc/xmlc-1.1.dtd";>
> <xmlc>
> <html encoding="ISO-8859-1"/>
> <compileOptions warnings="true"/>
> <inputDocument processSSI="true" documentFormat="xml"/>
> <documentClass createGetTagMethods="true"
> suppressGetElementMethods="true"
> deferParsing="true"
> dom="xhtml"/>
>
> <parser name="xerces"/>
> </xmlc>
> ----
>
> Good luck, and I hope to hear back from you pronto,
>
> Erik
>
> On Jan 25, 2007, at 3:01 AM, Jacob Kjome wrote:
> > BTW, can you try out 2.2.11 and see if you still have the problem
> > (I'm guessing you will) and then try out 2.2.10 and see it you
> > don't have the problem (I'm guessing you won't). And then I'll
> > take it from there to do some more research on why this is happening.
> >
> > Jake
> >
> > At 02:51 PM 1/24/2007, you wrote:
> > >Quoting Erik Rasmussen <rasmussenerik@xxxxxxxxx>:
> > >
> > >>
> > >> On Jan 24, 2007, at 7:58 PM, Jacob Kjome wrote:
> > >> > First, can you tell me which DOM you are using for both XMLC and
> > >> > for the loading
> > >> > of the "page2" document? Second, if you are using the XHTML DOM
> > >> > for XMLC
> > >> > loading, try using the HTML DOM instead and see if it works then.
> > >>
> > >> Are you referring to this line in my options.xmlc file?
> > >>
> > >> <inputDocument processSSI="true" documentFormat="xml"/>
> > >>
> > >> When I set it "html", all my jaxen xpath queries break with
> > NPE's. :-(
> > >>
> > >
> > >That's interesting. I don't recall what XMLC is doing with the
> > value of
> > >documentFormat? I've never even bothered to set it, so it must
> > default to
> > >either "xml" or "unspecified"...
> > >
> > ><!ATTLIST inputDocument documentFormat (xml|html|unspecified)
> > #IMPLIED>
> > >
> > >
> > >Anyway, try...
> > >
> > ><documentClass deferParsing="true" dom="xerces"/>
> > >or
> > ><documentClass deferParsing="true" dom="lazydom"/>
> > >
> > ><!ATTLIST documentClass dom (lazydom|xerces|generic|xhtml|wml|
> > voicexml|chtml)
> > >#IMPLIED>
> > >
> > >See the xmlc-1.1.dtd [1].
> > >
> > >The first 3 are valid for the HTML DOM, if your document is HTML
> > >("generic" is a
> > >synonym for "xerces"). If you don't set this, then you are using
> > "lazydom" by
> > >default, which would mean you are already using the HTML DOM. You
> > can also
> > >verify by calling getClass().getName() on one of your document nodes.
> > >
> > >> I'm loading both pages with XMLC.
> > >>
> > >> If I'm importing the whole node tree from one page into another,
> > how
> > >> the heck do I get the imported version of the node that i care
> > about
> > >> to call setIdAttribute() on it? :-(
> > >>
> > >
> > >Good question. But you shouldn't need to if you are using the
> > HTML DOM and it
> > >could be automated for the XHTML DOM inside and overridden
> > importNode(). I
> > >have to look into that.
> > >
> > >Let me know what you find. I suspect there may be some subtle bug
> > introduced
> > >when I modified HTMLDocument.getElementById(). If so, I'll need
> > to get both
> > >Xerces2 and XMLC's Xerces1 patched. Hopefully we can find a
> > solution without
> > >requiring a patch.
> > >
> > >> Erik
> > >
> > >Jake
> > >
> > >
> > >[1]
> > >http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/xmlc/xmlc/xmlc/
> > modu
> > >les/xmlc/src/org/enhydra/xml/xmlc/metadata/xmlc-1.1.dtd?
> > rev=1.4&conten
> > >t-type=text/vnd.viewcvs-markup
> > >
> > >
> > >
> > >
> > >
> > >--
> > >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
>
>
>

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

Previous by Date:	Re: [xmlc] 2.3beta getElementById() behavior, Erik Rasmussen
Next by Date:	Re: [xmlc] 2.3beta getElementById() behavior, Erik Rasmussen
Previous by Thread:	Re: [xmlc] 2.3beta getElementById() behavior, Erik Rasmussen
Next by Thread:	Re: [xmlc] 2.3beta getElementById() behavior, Erik Rasmussen
Indexes:	[Date] [Thread] [Top] [All Lists]