- From: Philippe Le Hegaret <plh@w3.org>
- Date: 29 Aug 2003 14:43:37 -0400
- To: Curt Arnold <carnold@houston.rr.com>
- Cc: WWW DOM <www-dom@w3.org>
On Fri, 2003-08-29 at 01:54, Curt Arnold wrote:
> >>documentURI: Should it be possible (or required) for an implementation
> >>to raise an exception if a new value is set that is not a valid URI.
> >>
> >>
> >
> >We didn't want to go into the issue of URI/IRI checking, so no exception
> >or error if you set to an invalid one. I clarified that no lexical
> >checking was done when setting documentURI. baseURI will return null if
> >an absolute URI cannot be determined. Note that we don't check the
> >xml:base attributes either.
> >
> >
> OK. Wanted to clarify that URI/IRI checking was intentionally omitted
> instead of overlooked. So an implementation would be non-conformant if
> it raised an exception on a malformed URI?
correct, since no lexical checking is done when setting the attribute.
> >>xmlEncoding: Can an implementation raise an exception if it does not
> >>recognize the encoding on setting? How is this affected by saves?
> >>Does this affect saves (which would be in the L/S spec)? Maybe it is
> >>cleaner just to allow the encoding to be specified on the save request.
> >
> >xmlEncoding has been changed to read-only, in order to simplify the
> >computation of the encoding used at save time (i.e. only
> >DOMOutput.encoding could be changed). Save defines an
> >"unsupported-encoding" error if the encoding is not supported.
> >
> I think that "lastEncoding" or "saveEncoding" is clearer.
better than xmlEncoding? but it is supposed to come from the XML
declaration, which is xmlEncoding and xmlStandalone follow the same
pattern.
> >We think that the current description is clear enough. Here are some
> >excerpts from the first paragraphs of the 2 methods:
> >
> >adoptNode:
> >[[
> >When possible, changes the ownerDocument of a node, its children, as
> >well as the attached attribute nodes if there are any.
> >]]
> >
> >importNode:
> >[[
> >Imports a node from another document to this document. [...] The source
> >node is not altered or removed from the original document; this method
> >creates a new copy of the source node.
> >]]
> >
>
> It would be good if the first sentences in each description were
> parallel. For example, adopt could say:
>
> Attempts to adopt a node from another document to this document. [...]
> If supported, the source node is removed from the original document
> and altered changing the ownerDocument of the node and any descendants,,,
How about:
[[
Attempts to adopt a node from another document to this document. If
supported, it changes the ownerDocument of the source node, its
children, as well as the attached attribute nodes if there are any. If
the source node has a parent it is first removed from the child list of
its parent. This effectively allows moving a subtree from one document
to another (unlike importNode() which create a copy of the source node
instead of moving it). When it fails, applications should use
Document.importNode() instead.
]]
> Is it an opening for an implementation to not attempt to adopt a node
> under any circumstances? That is
>
> class DocumentImpl implements Document
> public Node adoptNode(Node node) {
> // i'm not even going to try
> return null;
> }
> }
correct.
> There should be some statement of allowable changes to the source node
> in the event of a null return.
It is up to the implementation what is allowed or what is not. As
recommended in the description of adoptNode, use importNode if it fails.
> Could an adoptNode implementation detach
> the source node from its parent and then fail to add it to the target
> document?
No. It is an atomic operation, like insertBefore. If it fails, the
source node must not be detached from its parent.
> A Node return type was appropriate for importNode since it would create
> a new Node. For adoptNode, only acceptible return values appear to be
> the source node or null. The return value is just an expensive boolean.
Not exactly. Since DOM nodes can be proxies, the return object might
differ from the specified one. renameNode acts the same.
> This was discussed earlier. I was interpreting "fatal error" in the
> panic error (System.exit(-1)) sense.
Hopefully, this has been clarified in
http://lists.w3.org/Archives/Public/www-dom/2003JulSep/0140.html
Philippe
Received on Friday, 29 August 2003 14:43:45 UTC