Re: parentNode

At 28/07/98 02:47 PM , keshlam@us.ibm.com wrote:

>An argument about going one step further, putting the node in the context
>of a particular DocumentType (which will eventually define/constrain what
>its attributes and children may be), might be strongest. Though one could
>still argue that an "unattached" node could be created without checking,
>and then validated when it is actually being placed into the context of a
>particular document.

This was originally a lot of the reasoning behind DocumentFragment, since
the Document at that stage had a link to the DTD, you could find out
exactly what sort of elements and attributes were allowed by the content
model for that DocumentFragment, and build up parts of a document that way.
Especially with multiple documents with different DTDs...

There's also the question of how to cut parts out of a document, how to
model a user selection in terms of the document tree, ... and for all of
these things a DocumentFragment is handy. So if you map a user selection to
a selection in the document and somehow (we haven't got there yet, but one
day...) cut it out of the Document, you want to put it somewhere. The
DocumentFragment will be that somewhere, from which you can then copy the
contents somewhere else. (Don't start asking questions about how this will
all work; it's involved and we're concentrating on finishing Level 1. I
just wanted to show where the concept of DocumentFragment came from in the
first place).

>Question: Will there be a way to ask whether a Node is in fact attached
>only to a/the default DocumentFragment?

I'm not 100% sure I understand what this means, but I'll forward it to the
committee.

Lauren

Received on Tuesday, 28 July 1998 18:02:43 UTC