Re: Cut/Paste from one document to another

Stephen R. Savitzky" wrote:
> 
> At one point there was talk of relaxing some of the behavioral restrictions
> (e.g. live NodeLists and live children on EntityReference nodes) in a way
> that would preserve compatibility (in the sense that any Level 1
> implementation would be a Level 2 implementation, but not necessarily vice
> versa).  This would have made Level 2 easier to implement, more efficient,
> and more generally useful.  Right now it's the opposite.

Again, you're free to think so but that's not what W3C members think.
They are more than 350 and they include all the major industry players.
This said, we've never claimed to be done, and we all have a whole list
of things we'd like the DOM to address in the future.

> The DOM is, first and foremost, the object model for ECMAscript.

This is just plain wrong. Although the W3C DOM activity started from the
need for a standard for browsers, since day one the DOM Working Group
has counted more participants from companies that just aren't in the
browser market than the opposite. 
This said, it is true that we've been working with constraints coming
from the so called "level 0 browsers", but they represent by far the
largest installed base and we just can't ignore that. Whether you like
it or not.

>  It is
> almost unuseable in applications where documents are being created, edited,
> or transformed, because things like references to character entities,
> omitted end tags (permissible in HTML), whether or not attribute values are
> quoted, and the DTD are lost, making it impossible to reconstruct an
> original document.

To be exact: it is unusable for all of this if, and only if, you want to
keep any of these details. Representing every byte of a document has
never been a requirement for the DOM. On the contrary, from the start,
we've agreed that this was not a goal.
And for that matter, several W3C members intend to use/use the DOM in
authoring tools and don't care about any of these, just because people
that use authoring tools typically don't care about preserving any of
these.

>  (To give just one example, I might want to use a
> character entity to represent "@" in an e-mail address in order to foil
> spammers.  There doesn't appear to be any way to represent such a thing in
> the DOM, because character entities have to be converted to text on input.)

That's correct.

> Similarly, there's no general technique for adding arbitrary application-
> specific annotation to DOM nodes, such as would be needed for, e.g., a
> rendering engine.  This has to be done by means of application-specific
> extensions, which destroy portability.

We've discussed this specific issue but it was too late to put in DOM
Level 2. It should be in DOM Level 3.

> I'm not saying that the additional features of Level 2 aren't useful, just
> that they don't significantly extend the range of applications in which the
> DOM can be used.  It's still mainly aimed at scripting in the browser.

Again, not true. There are implementations of XSLT for instance, that
have been developed on top of the DOM, with one extension. This has
clearly nothing to do with a browser.

> Nevertheless, it would take only a few very minor extensions (such as the
> ability to represent the DTD, and a flag for omitted end tags) to make the
> DOM capable of representing any SGML document.

Our plans is to address DTD representation in Level 3. I don't know why
you'd need to represent omitted end tags though. You'd still need much
more to roundtrip a document byte for byte.

> Similarly, it would take
> only a few changes (to the behavioral spec, not even the interfaces) to make
> the DOM easier to implement, more efficient, and useful in a wider range of
> applications.

I guess you're mainly referring to the live aspect of the DOM, right?
Things just aren't as easy as you make it sound though. Making things
"dead" also brings its share of problems. But anyway, on our wish list
we've got things such as locks that hopefully should improve the
situation in the future.
-- 
Arnaud

Received on Wednesday, 1 September 1999 14:13:39 UTC