- From: Curt Arnold <carnold@houston.rr.com>
- Date: Sat, 30 Aug 2003 00:54:33 -0500
- To: www-dom@w3.org
> > >>>>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. > > AHA. I wasn't making the connection that xmlEncoding is the encoding specified in the XML declaration (seems pretty obvious now) and is orthogonal to the encoding of the initial source document and then encoding used in any subsequent saves. Would this be null if there were no XML declaration or no encoding specified in the declaration? Some implementations allow parsing from a string where the declared encoding is ignored. Would the xmlEncoding retain the value from the declaration (say UTF-8 or ISO-8859-1) when the source string was UTF-16? What would actualEncoding be in this case? > > >>>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. >]] > > OK
Received on Saturday, 30 August 2003 01:54:33 UTC