W3C home > Mailing lists > Public > www-dom-ts@w3.org > February 2004

Updated Python domts, and more issues

From: Andrew Clover <and-w3@doxdesk.com>
Date: Tue, 17 Feb 2004 20:19:16 +0000
To: www-dom-ts@w3.org
Message-ID: <20040217201916.GA18981@doxdesk.com>

Afternoon all,

I've updated the Python domts package to cope with the new TSML constructs
introduced recently. Also I added Twisted's 'microdom' to the implementations
module (for completeness more than anything - microdom does not claim to be
anything like a complete DOM implementation and so tests predictably poorly).

You can find the latest version at:

  http://www.doxdesk.com/file/software/py/domts.zip

(Not sure whether this should be incorporated into the main distribution/CVS
or whether I should publish it properly independently; in any case I'll try to
keep the package at this URL up-to-date for the moment.)

The tests seem to be much improved from the last snapshot I tried - thanks
Curt, good work! - however there are still a few issues here and there:

Level 1 Core:

hc_elementnormalize
  This test checks that a nodeValue will be character 948, but if the
  implementation does not expandEntityReferences this node will be an entity
  reference, hence its value will be null.

hc_elementnormalize2
  Checks the element's firstChild, should be its attribute's firstChild.

Level 2 Core:

namednodemapsetnameditemns03
  The Attr being set is already owned, so the test could just as well raise
  INUSE_ATTRIBUTE_ERR as WRONG_DOCUMENT_ERR.

attrgetownerelement01, attrgetownerelement04, documentimportnode02,
documentimportnode03, documentimportnode04, elementgetattributenodens03,
elementgetattributens02, elementhasattribute02, hasAttributeNS04,
importNode05, importNode06, namednodemapremovenameditemns02, nodesetprefix04
  Require implementationAttribute 'validating'.

Level 3 Core:

documentadoptnode05
  Wrong namespaceURI is being checked for, it should be same as in original
  document. Adopting a node does not change its namespace.

nodegettextcontent19
  This test assumes that a non-'validating' implementation won't be able to
  detect ElementContentWhitespace. However according to infoset whilst a
  non-validating parser is not obliged to make this information item known,
  it is not prohibited from doing so either. With the ELEMENT declaration for
  body being in the internal subset of barfoo.xml, there is no reason a non-
  validating parser should be unable to determine the content model. So
  the results '\nbar\n' or 'bar' are equally possible.

textreplacewholetext08
  Creates an unbound entity reference 'beta'; should presumably be 'ent2'.

domconfigelementcontentwhitespace1
  assertTrue/False inside the <if> are the wrong way round.

domconfigerrorhandler1
  cantSetTrue is not easily supportable in dynamically-typed languages,
  Python in particular. Officially, IDL boolean is still bound to Python
  integer, however in the meantime integer has become a type that can be
  extended (eg. by the new native boolean type in Python 2.3), so it's
  entirely possible to have an object that's both a boolean and an
  ErrorHandler! There are arbitrary approaches one could take to detecting
  non-handler objects (eg. method-sniffing), but in the absence of static
  typing there's no watertight solution.

domconfigschemalocation1
  Parameter is optional. canSetURI may fail, especially for non-validating
  implementations.

documentnormalizedocument06, documentnormalizedocument07
  "everything else should be -1 or null" - why? An implementation might
  usefully pass eg. the documentURI; AFAICS spec doesn't forbid this and
  it could conceivably be useful.

documentnormalizedocument06
  Typo, cdata-sections-splitted should be cdata-section-splitted.

Level 3 LS:

LSSerializerConfig8, LSSerializerConfig10
  These tests are now out of date, namespace-declarations and well-formed
  can be set false for serialisers in the February PR.

Add to bugtracker [Y|N]?

Cheers,

-- 
Andrew Clover
mailto:and@doxdesk.com
http://www.doxdesk.com/
Received on Tuesday, 17 February 2004 15:41:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:04 UTC