Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #10915
| Path | csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!newsfeed.straub-nv.de!newsout01.versatel.de!news.versatel.de!not-for-mail |
|---|---|
| From | Michael Jung <miju@golem.phantasia.org> |
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: xml:id |
| Date | Tue, 20 Dec 2011 22:54:20 +0100 |
| Lines | 80 |
| Message-ID | <871uryewoj.fsf@golem.phantasia.org> (permalink) |
| References | <87wr9t1uxp.fsf@golem.phantasia.org> <33c64ae6-d7f1-466b-8534-35f777eb3c7c@h4g2000yqk.googlegroups.com> <87ehw0ap2i.fsf@golem.phantasia.org> <zHIHq.27163$8O1.9231@newsfe07.iad> <87vcpctozy.fsf@golem.phantasia.org> <y_NHq.26052$Q83.9160@newsfe17.iad> |
| NNTP-Posting-Host | i59f772af.versanet.de |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset=us-ascii |
| X-Trace | news01.versatel.de 1324418060 12882 89.247.114.175 (20 Dec 2011 21:54:20 GMT) |
| X-Complaints-To | abuse@versatel.de |
| NNTP-Posting-Date | Tue, 20 Dec 2011 21:54:20 +0000 (UTC) |
| User-Agent | Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
| Cancel-Lock | sha1:V56sP2L/mDBzwSZZJAA9jKx7jiE= |
| Xref | x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10915 |
Show key headers only | View raw
Arved Sandstrom <asandstrom3minus1@eastlink.ca> writes:
> On 11-12-19 02:06 PM, Michael Jung wrote:
>> Arved Sandstrom <asandstrom3minus1@eastlink.ca> writes:
>>> On 11-12-19 05:27 AM, Michael Jung wrote:
>> [...]
>>> Not "forgotten" exactly. I tested with JDK 1.6 and 1.7, and I find that
>>> if the adopted node is placed _somewhere_ (appendChild or what have
>>> you), that if you obtain the list of "elem" elements in the new
>>> document, that you'll have 2 of them, and that if you inspect the isId()
>>> value of the 'id" attributes, that both of them are TRUE.
>>> Furthermore, if you retrieve by getElementById(), using "x" actually
>>> returns an element, but using "x2" does not. So that tells me that
>>> things are dubious overall if you've performed your scenario.
[...]
>> Document parsed = docBuilder.parse(new File("src/test.xml"));
>> Element el = parsed.getElementById("x");
>> System.out.println(el);
>>
>> Document parsed2 = docBuilder.parse(new File("src/test2.xml"));
>> Element el2 = parsed2.getElementById("x");
>> System.out.println(el2);
>>
>> parsed2.adoptNode(el);
>> //parsed2.getDocumentElement().removeChild(el2);
>> //parsed2.getDocumentElement().appendChild(el);
>> parsed2.getDocumentElement().replaceChild(el, el2);
>> System.out.println(parsed2.getElementById("x"));
[...]
>> setIdAttribute seems out of place. It's not likely that the schema
>> changes in that respect but it still is odd. And parsing the schema
>> separately just for that is overkill. At least this issue could be
>> documented somewhere in the javadoc (I couldn't find anything). Now,
>> if there were a getIdAttribute that would be better.
[...]
> So we surmise that we have to take the adopted/imported "elem" element,
> and parent it somewhere, where if "Something Else" (TM) happened that
> the "id" attribute would be identified as being of xs:ID type.
Clear enough. The println's up in the code come for free.
> I might add at this juncture, I'm not convinced that your
>
> parsed2.getDocumentElement().replaceChild(el, el2);
>
> will work. Node el2 is in document 2, but el is still in document 1.
It was adopted. That should move it out of doc-1 and somewhere in the
"orphanage" of doc-2. (At least that is what the javadoc says.) Also
parsed2.adoptNode(el).equals(el) evaluates to true.
> That's why the returned value from adoptNode() is handy. replaceChild()
> does work just fine if you use that value.
Tried that and removed the setIdAttribute; fails.
> I would not expect any of these methods to re-validate and therefore I
> am not surprised that if this is all we do, that the newly parented
> adopted/imported node is not found with getElementById().
That would invalidate a document any time a node is added (and removed).
I understand that this is due to performance, but shouldn't there be
helper methods that verify that the document is valid after some
transformation? And some hints in the javadoc? The only way I see out of
this (if I had deep ids) is by transforming and reparsing the full
document.
> We also know that at this point that setIdAttribute() sets things
> right. [...] So I think we're stuck with setIdAttribute().
See above. Luckily I don't have deep ids. (Some XPath would help that,
of course. But it all seems overkill.)
> I'm no expert at DOM (I hate it actually :-)) but I hope the above
> analysis shows why I at least am not particularly surprised that all of
> this has to be done.
I get the point :-)
Michael
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread
xml:id Michael Jung <miju@golem.phantasia.org> - 2011-12-18 21:33 +0100
Re: xml:id Lee Fesperman <firstsql@gmail.com> - 2011-12-19 00:24 -0800
Re: xml:id Michael Jung <miju@golem.phantasia.org> - 2011-12-19 10:27 +0100
Re: xml:id Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-19 11:25 -0400
Re: xml:id Michael Jung <miju@golem.phantasia.org> - 2011-12-19 19:06 +0100
Re: xml:id Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-19 17:26 -0400
Re: xml:id Michael Jung <miju@golem.phantasia.org> - 2011-12-20 22:54 +0100
csiph-web