- From: Dominic Chambers <dominic.chambers@bigfoot.com>
- Date: Mon, 4 Nov 2002 19:51:30 +0100
- To: "Philippe Le Hegaret" <plh@w3.org>
- Cc: "WWW DOM" <www-dom@w3.org>
I am not sure I completely understand your point: Phillipe Wrote: > And each Node would have a different set of parameters? or would you > only support the parameters on the DOMBuilder of the Document and then > the Node is only reusing them? I don't think it would make sense to > support this method on one set of Nodes and not an other either. What I am saying is that the DocumentLS interface would be far more usedul if it was implemented by Nodes instead (i.e. NodeLS). Or, if there is some good reason for not doing that, which I imagine there will be, then an extra optional parameter could be added to the methods of DocumentLS so that they allowed the node to load or save from to be specified. I should have explained my intent better, but I think it would be very useful to be able to load and retrieve XML (particulary strings) from nodes (typically elements). Lots of people use this feature regularly (using innerHTML) because working with elements that are interleaved with text nodes becomes confusing, and extremely verbose using the DOM only. Of course, loading and saving from nodes can be achieved with the current spec. using the DOMBuilder. And, to reiterate, I do think that the DOMBuilder is a very strong interface, since it allows access to so many advanced features, and is not too complicated for occasional use. But the verbosity of that method, and the sheer number of times DOM applications need to load XML into elements means that code quickly becomes unreadable. The current spec standardizes the load and loadXML methods, but provides nothing like the even more useful innerHTML attribute. A simple method for quickly getting XML into elements is necesarry for all but trivial DOM work, and the current method is too verbose for an operation that occurs so often. Dominic.
Received on Tuesday, 5 November 2002 01:58:58 UTC