Re: DocumentFragment and load/loadXML

> On Tuesday, 10/29/2002 at 09:11 EST, "Dominic Chambers"
> <dominic.chambers@bigfoot.com> wrote:
> > Therfore, shouldn't the DocumentLS interface be implemented by
> > DocumentFragment objects also?
>
> I think not. The meaning and usage of DocumentFragment has changed
> somewhat as the DOM has evolved, and the quoted paragraphs should not be
> taken overly literally.
>

Yes I do see you point. I myself never use DocumentFragment normally, but
was hoping to offer a sensible way to allow loading into a node.

> In particular: Every DocumentFragment exists in the context of a specific
> Document node, which carries the factory methods for creating more nodes
> compatable with that DocumentFragment. Since Load can be considered
> another kind of node factory, I think it makes perfect sense for Load to
> be associated with the Document rather than the fragment, and Save would
> remain on the Document for reasons of symmetry.
>
> It is certainly desirable to be able to load XML source into the context
> of an existing Document (rather than loading into a new Document and
> having to import/adopt them), and quite possibly to insert them into a
> DocumentFragment in the process of doing so... but as long as the APIs
> support that operation I don't think the methods themselves need to be
> duplicated on DocumentFragment.
>

Yes, I agree, loading XML into nodes should be possible without creating
a new Document and importing. The problem as I see it, is that there are
two ways of using Load and Save: the easy way and the hard way. This
makes sense since Load and Save has so many nice features when you go
the full distance and create a DOMBuilder.

But, the easy way does not allow users to import or export directly from a
node, which is a common desire, and is already provided by both IE and
Mozilla using the proprietary innerHTML method. This leaves the hard way
of achieving this conceptually simple task.

For example, node.innerHTML = xml, would be written as:

    var domBuilder = document.createDOMBuilder(
        document.MODE_SYNCHRONOUS);
    var inputSource = document.createDOMInputSource();

    inputSource.stringData = xml;
    domBuilder.parseWithContext(inputSource, node, DOMBuilder.REPLACE);

Notice that in this example we are not using entity resolvers, error
handlers,
feature determination, character decoding, XML base, asynchronous
download, or any of the good stuff that Load and Save offers the more
advanced
user.

So there seems to be a disparity between a synchronous uri or string load
into a
document, and the same thing into a node. The node is definately a second
class
citizen in this model.

Is there a reason for this disparity, and does it have anything to do with
the fact that
IE currently provides load and loadXML for documents, but not for nodes?
Would
it change anything if these methods (or some other similar methods) were
made
available for nodes and they never supported it? Wouldn't users of that
implementation
still be in the same position - unable to perform this task without using
proprietary
methods?


Regards, Dominc.


>  ______________________________________
> Joe Kesselman  / IBM Research

Received on Thursday, 31 October 2002 22:25:41 UTC