You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Matt Hastie <m....@citr.com.au> on 2000/08/11 19:00:06 UTC
Bug Report: replaceChild on the Document node fails
Greetings,
It would appear calls to replaceChild on a Document fail in Xerces-J 1.1.3.
This is manifested in the following code which fails, writing "old" to
stderr:
Document document = new DocumentImpl();
Element element0 = document.createElement("old");
Element element1 = document.createElement("new");
document.appendChild(element0);
document.replaceChild(element1, element0);
System.err.println(document.getDocumentElement().getTagName());
Regards,
Matt Hastie.
---------------------------------------------------------------
Matt Hastie
Software Architect
email: m.hastie@citr.com CiTR Inc
phone: 303 417 0575 4750 Walnut Street #106
fax: 303 385 0386 Boulder CO, USA 80301
---------------------------------------------------------------
Re: replaceChild on the Document node fails
Posted by Sven Doerr <do...@time4you.de>.
Arnaud Le Hors wrote:
>
> You're right, there is a bug. But it's not what you think though. Per
> the DOM spec you're not actually supposed to be able to change the
> document element at all. You should get a NO_MODIFICATION_ALLOWED_ERR
> exception. I suspect that the right behavior won't satisfy you though...
hmm. i personally would even like to have a method
like createDocument(null,null,null) to create a doc
without a root element.
in fact dom always needs a document for the elements;
but if one uses dom as a "data" structure just for
transforming it later on, it might be quite irrelevant,
what "document" the element is in, if no validation
against a dtd shall be performed and no encoding
is needed for the "document".
especially if i commonly want to create elements
as the result of some methods: only after i finally have
the result element computed, only THEN i can put this result
at the top of the actual document, e.g. to serialize
or transform it.
i cannot always know in advance what tag name the
top level element will have.
and if i already have a root element, i would have to make
waste of it. and if i cant even change it, i would have
to do some inefficient remove/append or even import operations.
to be extreme: if always only valid documents could
be represented by an implementation, it would be
impossible to actually begin to construct the document !
a similar example: xslt does not prevent a stylesheet
to include more than one rule matching a toplevel element
(like match="/page", and somewhere else match="/frames" ).
it does not force too much to become inconvenient.
so i think a implementation becomes more easily USABLE if
it allows documents without a document element and with
the possibility for replacement.
sven dörr
RE: Bug Report: replaceChild on the Document node fails
Posted by Matt Hastie <m....@citr.com.au>.
The reason why we need to change the document element is simply because
we're using a document as an inout parameter to a method like:
void processXML(Document xmlDocument);
The document passed may contain a 'request' document element upon entry, and
contain a 'response' or 'error' document upon exit. There defect here is
probably
that we're using the document as a container for a document, rather than a
document
itself.
There are a couple of fixes around this:
a) redesign the DTD to have a document element that is common to all
messages, or
b) redesign the Java interface.
Actually, in the case where the bug was detected, the replaced document
element
is unchanged, and we were just replacing the complete document for
convenience.
If we didn't have the capacity to replace the document element in this case,
we'd
need to write code that removes the children under the existing document
element,
just to replace them with other set.
Perhaps replacing the document element with an identically tagged document
element
could be a vaild operation, providing the implementations were the same.
Regards,
Matt.
> -----Original Message-----
> From: Arnaud Le Hors [mailto:lehors@us.ibm.com]
> Sent: Friday, August 11, 2000 15:12
> To: xerces-j-dev@xml.apache.org
> Subject: Re: Bug Report: replaceChild on the Document node fails
>
>
> Matt Hastie wrote:
> >
> > Yeah,
> >
> > I would guess that this is the case as it would involve changing the
> > Document docType to reflect the new document contents - this
> would appear to
> > be illegal through any API mechanism on the DOM level 2 core.
> >
> > At present, we're using the removeChild()/appendChild() combo as a
> > work-around
> > to replaceChild, but this would appear to be illegal from the
> specification
> > standpoint as well - should Xerces throw NO_MODIFICATION_ALLOWED_ERR in
> > response to any attempt to alter a document element?
>
> Yes, it should. Note that in a vanilla implementation such as Xerces
> this may seem rather stupid but there is a good reason behind it. In
> some implementations the actual classes used may be different depending
> on the type of document you're dealing with. For instance, an
> implementation which supports SVG DOM and MathML DOM is likely to have
> two different sets of classes for its nodes. Changing the document type
> and/or the document element in such a context can simply be impossible.
> Could you explain why you have to do that? Will you be stuck if I fixed
> our implementation to conform to the spec or will you be able to cope
> with it?
> --
> Arnaud Le Hors - IBM Cupertino, XML Technology Group
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
Re: Bug Report: replaceChild on the Document node fails
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Matt Hastie wrote:
>
> Yeah,
>
> I would guess that this is the case as it would involve changing the
> Document docType to reflect the new document contents - this would appear to
> be illegal through any API mechanism on the DOM level 2 core.
>
> At present, we're using the removeChild()/appendChild() combo as a
> work-around
> to replaceChild, but this would appear to be illegal from the specification
> standpoint as well - should Xerces throw NO_MODIFICATION_ALLOWED_ERR in
> response to any attempt to alter a document element?
Yes, it should. Note that in a vanilla implementation such as Xerces
this may seem rather stupid but there is a good reason behind it. In
some implementations the actual classes used may be different depending
on the type of document you're dealing with. For instance, an
implementation which supports SVG DOM and MathML DOM is likely to have
two different sets of classes for its nodes. Changing the document type
and/or the document element in such a context can simply be impossible.
Could you explain why you have to do that? Will you be stuck if I fixed
our implementation to conform to the spec or will you be able to cope
with it?
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
RE: Bug Report: replaceChild on the Document node fails
Posted by Matt Hastie <m....@citr.com.au>.
Yeah,
I would guess that this is the case as it would involve changing the
Document docType to reflect the new document contents - this would appear to
be illegal through any API mechanism on the DOM level 2 core.
At present, we're using the removeChild()/appendChild() combo as a
work-around
to replaceChild, but this would appear to be illegal from the specification
standpoint as well - should Xerces throw NO_MODIFICATION_ALLOWED_ERR in
response to any attempt to alter a document element?
Regards,
Matt.
> -----Original Message-----
> From: Arnaud Le Hors [mailto:lehors@us.ibm.com]
> Sent: Friday, August 11, 2000 13:56
> To: xerces-j-dev@xml.apache.org
> Subject: Re: Bug Report: replaceChild on the Document node fails
>
>
> You're right, there is a bug. But it's not what you think though. Per
> the DOM spec you're not actually supposed to be able to change the
> document element at all. You should get a NO_MODIFICATION_ALLOWED_ERR
> exception. I suspect that the right behavior won't satisfy you though...
> --
> Arnaud Le Hors - IBM Cupertino, XML Technology Group
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
Re: Bug Report: replaceChild on the Document node fails
Posted by Arnaud Le Hors <le...@us.ibm.com>.
You're right, there is a bug. But it's not what you think though. Per
the DOM spec you're not actually supposed to be able to change the
document element at all. You should get a NO_MODIFICATION_ALLOWED_ERR
exception. I suspect that the right behavior won't satisfy you though...
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group