ownerDocument confusion

[James Margaris <jm...@nexaweb.com>]

I am having a bit of trouble figuring out how the DOM spec says owner
document should be treated, and how we can reconcile that with what we
need. We certainly have some issues around our ownerDocument and
_ownerDocument. (Yes we have both) I think this is because there are two
concepts at work here:

1: What document did this element originate from?
2: Is this element currently part of that document? (Has a path up to
the document)

For example if you create an element from a doc but then never do
something with it the ownerDocument should point to that document, but
the element is not actually a part of it.

We use "ownerDocument" and "_ownerDocument" to track these ideas in a
confusing fashion. In addition the "ownerDocument" field is not kept up
to date by cloning and we don't have an "importNode()" implementation.
This is a big issue because the xpath id() function relies on
ownerDocument.

My proposal:

1: ownerDocument will track what it is supposed to track according to
spec - the document the node was created from.
2: importNode() will be introduced and will correctly update
ownerDocument on the imported nodes.
3: We will disallow moving elements between documents without the use of
importNode()
4: We will hide/remove/rename our implementation of cloneNode(), since
it is used to copy between documents but does not track ownerDocument.
5: We will introduce separate methods/variables to keep track of whether
or not the current node has a path to the document root. We need this
concept for our document level attribute/structure listeners, among
other reasons. Once an element is removed from a document it should not
fire document level structure/attribute changes, but technically the
"ownerDocument" has not changed.

Sound reasonable?

James Margaris

RE: ownerDocument confusion

[James Margaris <jm...@nexaweb.com>]

 importNode() takes a deep flag so that will give us the ability to
recursively import.

You can clone a node by doing this:

element.ownerDocument.importNode(element /*,deep */);

This will clone the original node, the difference here is that it clones
it and makes it suitable for inclusion into a specific document.

In xmodify we would do something like this instead:

uiDocument.importNode( element, true );

Which clones the node and makes it suitable for the UI doc. Right now
"suitable for a document" doesn't really mean much but I think we should
encourage that usage because later on if moving dom nodes from one doc
to another does involve something all the code will already be using the
proper import.

So I would vote removing cloneNode() as devs can clone the nodes as
above in a standard way.

James

-----Original Message-----
From: Bob Buffone [mailto:rbuffone@nexaweb.com] 
Sent: Tuesday, September 12, 2006 8:59 PM
To: xap-dev@incubator.apache.org
Subject: RE: ownerDocument confusion

Looking at the Java org.w3c.dom.Document, we should also provide the
ability to import the whole node tree or just the node.

Also we should probably leave the cloneNode as it allows developers to
replicate the node or node tree.  There is now way specify this if we
just reply on clone().

Bob (Buffone)

-----Original Message-----
From: James Margaris [mailto:jmargaris@nexaweb.com]
Sent: Monday, September 11, 2006 8:03 PM
To: xap-dev@incubator.apache.org
Subject: ownerDocument confusion

I am having a bit of trouble figuring out how the DOM spec says owner
document should be treated, and how we can reconcile that with what we
need. We certainly have some issues around our ownerDocument and
_ownerDocument. (Yes we have both) I think this is because there are two
concepts at work here:

1: What document did this element originate from?
2: Is this element currently part of that document? (Has a path up to
the document)

For example if you create an element from a doc but then never do
something with it the ownerDocument should point to that document, but
the element is not actually a part of it.

We use "ownerDocument" and "_ownerDocument" to track these ideas in a
confusing fashion. In addition the "ownerDocument" field is not kept up
to date by cloning and we don't have an "importNode()" implementation.
This is a big issue because the xpath id() function relies on
ownerDocument.

My proposal:

1: ownerDocument will track what it is supposed to track according to
spec - the document the node was created from.
2: importNode() will be introduced and will correctly update
ownerDocument on the imported nodes.
3: We will disallow moving elements between documents without the use of
importNode()
4: We will hide/remove/rename our implementation of cloneNode(), since
it is used to copy between documents but does not track ownerDocument.
5: We will introduce separate methods/variables to keep track of whether
or not the current node has a path to the document root. We need this
concept for our document level attribute/structure listeners, among
other reasons. Once an element is removed from a document it should not
fire document level structure/attribute changes, but technically the
"ownerDocument" has not changed.

Sound reasonable?

James Margaris

RE: ownerDocument confusion

[Bob Buffone <rb...@nexaweb.com>]

Looking at the Java org.w3c.dom.Document, we should also provide the
ability to import the whole node tree or just the node.

Also we should probably leave the cloneNode as it allows developers to
replicate the node or node tree.  There is now way specify this if we
just reply on clone().

Bob (Buffone)

-----Original Message-----
From: James Margaris [mailto:jmargaris@nexaweb.com] 
Sent: Monday, September 11, 2006 8:03 PM
To: xap-dev@incubator.apache.org
Subject: ownerDocument confusion

I am having a bit of trouble figuring out how the DOM spec says owner
document should be treated, and how we can reconcile that with what we
need. We certainly have some issues around our ownerDocument and
_ownerDocument. (Yes we have both) I think this is because there are two
concepts at work here:

1: What document did this element originate from?
2: Is this element currently part of that document? (Has a path up to
the document)

For example if you create an element from a doc but then never do
something with it the ownerDocument should point to that document, but
the element is not actually a part of it.

We use "ownerDocument" and "_ownerDocument" to track these ideas in a
confusing fashion. In addition the "ownerDocument" field is not kept up
to date by cloning and we don't have an "importNode()" implementation.
This is a big issue because the xpath id() function relies on
ownerDocument.

My proposal:

1: ownerDocument will track what it is supposed to track according to
spec - the document the node was created from.
2: importNode() will be introduced and will correctly update
ownerDocument on the imported nodes.
3: We will disallow moving elements between documents without the use of
importNode()
4: We will hide/remove/rename our implementation of cloneNode(), since
it is used to copy between documents but does not track ownerDocument.
5: We will introduce separate methods/variables to keep track of whether
or not the current node has a path to the document root. We need this
concept for our document level attribute/structure listeners, among
other reasons. Once an element is removed from a document it should not
fire document level structure/attribute changes, but technically the
"ownerDocument" has not changed.

Sound reasonable?

James Margaris