[gdome]DOM compliance, bugs

[Tobias Peters <t-peters gmx de>]

Hi,

because I want to declare libgdome-ruby and libgdome-cpp stable soon after
the 0.7.0 release of gdome2, I'm currently implementing extensive DOM Core
compliance tests for the ruby wrapper, testing every method of every
interface, aiming to invoke every possible response of a method.

This seems to be a slow process, especially because it is not always or
immediately clear what the methods inherited from Node are supposed to do
in the derived classes. Does anyone know of a collection of anwers to
perceived ambiguities in the DOM 2 Core specification, or existing
compliance tests for other DOM implementations? So far, I have found only
tests in PyXML, but they seem to be far from complete, and are not of much
use.

If anyone wants to help implementing the tests, I'd really welcome it.

Here is what I found so far (for DocumentType):

- Differences to the DOM 2 Core specification:

  * 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?


  * 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.

  * 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


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).

So long,
 Tobias