Re: [gdome]DOM compliance, bugs
- From: Paolo Casarini <casarini CS UniBO IT>
- To: Tobias Peters <t-peters gmx de>
- Cc: gdome gnome org
- Subject: Re: [gdome]DOM compliance, bugs
- Date: Thu, 6 Dec 2001 13:39:29 +0100 (CET)
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
Fixed on CVS.
> * DocumentType::parentNode returns null when validating with external
> 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
> The spec sais on page 38, this exception is "raised if this node is
> 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
> Notice the contrast of the current choice to (c).
Now ::replaceChild checks for NO_MODIFICATION_ALLOWED_ERR before checking
All gdome API should check before NO_MODIFCATION_ALLOW_ERR Exception
because is a simple operation (O(1)) and then for all the others
] [Thread Prev