Re: [gdome]DOM compliance, bugs

[Paolo Casarini <casarini CS UniBO IT>]

On Thu, 25 Oct 2001, Tobias Peters wrote:

>   * setting DocumentType::nodeValue raises exception
> 
>     The current implementation throws NO_MODIFICATION_ALLOWED_ERR.
>     The spec says on page 37, description of Node::nodeValue:
>     > nodeValue of type DOMString [p.17]
>     >    The value of this node, depending on its type; see the table
>     >    above. When it is defined to be null, setting it has no effect.
>     The table mentioned here appears on page 36 and lists "null" as the
>     value of nodeValue.
>     I think, "setting has no effect" forbids to throw an exception.
>     Maybe other node types with a null nodeValue are also affected?
With a DOM Level 2 implementation you can't modify a DocumentType node so
any DocumentType node are readonly and NO_MODIFICATION_ALLOWED_ERR is the
right way to manage gdome_dt_set_nodeValue.

>   * DocumentType::childNodes returns null
> 
>     The specification says on page 37, description of Node::childNodes:
>     > childNodes of type NodeList [p.43] , readonly
>     >   A NodeList [p.43] that contains all children of this node. If
>     >   there are no children, this is a NodeList containing no nodes.
>     DocumentType is one of the node types that can never have children. I
>     think the spec wants that an empty Nodelist is returned even in this
>     case.
Fixed on CVS.


>   * DocumentType::parentNode returns null when validating with external
>     dtd:
> 
>     The specification lists DocumentType as a possible child of Document
>     (Page 15, Section 1.1.1), so DocumentType::parentNode should return
>     the Document node.
>     Here is an example document. When loaded from memory in validating
>     mode, DocumentType::parentNode returns null:
> 
>     <?xml version="1.0"?><!DOCTYPE ex SYSTEM "ex.dtd"><ex/>
> 
>     File ex.dtd contains only: <!ELEMENT ex EMPTY>
> 
>     When the !ELEMENT declaration is included as an internal subset,
>     DocumentType::parentNode correctly returns the Document node.
> 
>   * DocumentType::nextSibling and DocumentType::previousSibling are
>     affected in the same way as DocumentType::parentNode
Fixed on CVS.


> The following list contains remarks on the exceptions thrown by some
> methods, that could also throw different exceptions or no exception.
> I think their current behaviour in gdome is correct, but is only one of
> several possible ways to behave, and it may not be the most consistent
> one. Feel free to ignore this list.
> 
> When a method fails, and more than one error causes it to fail, how
> does it decide what exception code it should return?
> 
>   (a) setting attribute DocumentType::prefix raises Exception
>       "NO_MODIFICATION_ALLOWED_ERR"
> 
>       The spec sais on page 38, this exception is "raised if this node is
>       readonly."
>       Is a document type node always classified as readonly?
> 
>       Another possibility would be to ignore the call quietly, like
>       setting DocumentType::nodeValue should behave.
> 
>   (b) DocumentType::removeChild raises "NO_MODIFICATION_ALLOWED_ERR".
> 
>       This is permitted by the DOM specification. It emphasizes a readonly
>       aspect of a node.
> 
>       Alternatively, this could raise "NOT_FOUND_ERR", and emphasize the
>       childlessness of the node.
> 
>   (c) DocumentType::appendChild raises "NO_MODIFICATION_ALLOWED_ERR"
> 
>       "HIERARCHY_REQUEST_ERR" would also be possible
> 
>   (d) DocumentType::replaceChild raises "HIERARCHY_REQUEST_ERR"
> 
>       "NO_MODIFICATION_ALLOWED_ERR" and "NOT_FOUND_ERR" would also be
>       possible.
> 
>       Notice the contrast of the current choice to (c).
Now ::replaceChild checks for NO_MODIFICATION_ALLOWED_ERR before checking
for HIERARCHY_REQUEST_ERR.

All gdome API should check before NO_MODIFCATION_ALLOW_ERR Exception
because is a simple operation (O(1)) and then for all the others
possible Exceptions.


Thanx,
   paolo.