W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2003

Re: L3 Core Document comments

From: Curt Arnold <carnold@houston.rr.com>
Date: Sat, 30 Aug 2003 00:54:33 -0500
Message-ID: <3F503C19.10407@houston.rr.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:57 GMT