Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10883

Re: xml:id

Show all headers | View raw

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.
> [...]
> 
> Some of this code was apparently garbled in my attempt to tone the
> working example down. Here is some changed code that still yields the
> output above.
> 
> [...]
>    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"));
> [...]
> 
> (Create a copy of test.xml called test2.xml.) What I am attempting to
> achieve should be obvious by now: replace one node with the other from
> a different file.  The commented out lines replacing the one following
> them also doesn't work.
> 
>> What *does* work is to (1) remove the first element, the one with value
>> "x", and (2) to then setIdAttribute() on the adopted/placed node with id
>> attribute of "x2".
> 
> That is true: ie. putting "el.setIdAttribute("id", true);" somewhere
> in the code above.  This way I need to know the id attribute's name,
> but I can live with that.
> 
>> Maybe I'm missing something, but if you're willing to call adoptNode()
>> in the course of doing what you're doing, what's the problem with
>> removing the element that is going to conflict, and also calling
>> setIdAttribute()?
> 
> 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.
> 
> Thanks.
> 
> Michael

I can sort of see why we end up with these problems. Neither adoptNode
nor importNode provide a parent for the adopted/imported node in the
target document, which is why both methods return the actual
adopted/imported node (one that has the correct owner document).

Until we know where the adopted/imported node is placed in the target
document, it's not possible to determine whether attribute "id" of
element "elem" is actually of type xs:ID. As you know we could easily
have a schema that declares two elements at different places in the
hierarchy, each with tag name "elem", each with an attribute "id", where
those 2 attributes could either none of them, one of them or both of
them be declared as type xs:ID.

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.

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.
That's why the returned value from adoptNode() is handy. replaceChild()
does work just fine if you use that value.

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

We also know that at this point that setIdAttribute() sets things right.
I experimented with Document.normalizeDocument() and tweaking some
DOMConfiguration parameters in the hopes of finding a way of at least
not having to specify the xs:ID attribute. But this seems not to work.
So I think we're stuck with setIdAttribute().

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.

AHS

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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