Re: DOM Level 3 LS test results

I've logged bug 441 for the (hopefully) non-controversial items and have 
committed changes as described.

Andrew Clover wrote:

>Sander Bos <sander@x-hive.com> wrote:
>
>  
>
>>I now finally ran the LS tests (from CVS) against our implementation.
>>    
>>
>
>Coincidentally, I just finally ran them against mine too!
>
>Speaking of which, if anyone is interested in running DOMTS against Python
>implementations, this may be useful:
>
>  http://www.doxdesk.com/file/software/py/domts.zip
>
>  
>
>>that can explain some of the errors (e.g. in the missing
>>parameter department), but not all...
>>    
>>
>
>Indeed. I've got a whole bunch more issues, which I'll dump here on the list
>for the moment (because its a bit much to file single Bugzilla reports on).
>
>----
>
>DOMBuilderTest3: there is whitespace in test2.xml, but the test assumes it
>will be ignored for some reason. Also the final <nodeName> refers to
>secondElt1 when clearly it should be thirdElt. On a related note, is it
>safe to put a <?xml text declaration at the start of a file used by
>parseWithContext? As far as I can see, the LS specification says nowhere
>whether an 'XML fragment' is the same thing as an external parsed entity.
>(If it's not, files like this could fail due to an invalid processing
>instructions.)
>  
>
I've fixed the thirdElt problem and stripped test2.xml of whitespace and 
the XML declaration.  However, the question on exactly what parser with 
context needs to support is a good one and worthy of independent tests.

>DOMBuilderTest5: the DOMConfiguration parameters are wrong, containing
>underscores instead of hyphens. Also supported-media-types-only is an
>optional feature - should check canSetParameter first.
>  
>
The underscores are in the names of the local variables that contain the 
string values.  The values themselves should have hyphens.  I have 
changed the test to support the optionality of 
supported-media-types-only.  Fully running the test would require 
accessing an HTTP server that reports an unsupported media type, loading 
a file from the file system, even if its extension is .pdf should not be 
sufficient.  I've put in a temporary http://localhost URL.  Several of 
the serialization tests also require a properly condifigured HTTP 
server, however none of my available implementations can get far enough 
to fail due to its absense.

>DOMBuilderTest6: I don't see where the spec states that parsing an empty
>input results in null - it only mentions null return values for async parsers.
>An empty Document or some kind of error might also be possible?
>  
>

This should result in an fatal error being reported to the error 
handler.  I've assumed that any fatal error during a parse would result 
in a null return value, there is no provision for throwing a checked 
exception (such as an io exception) and returning a partial document 
would break XML's requirement that you can't ignore fatal errors.  
However, the spec should be more explicit on the return value and/or 
exceptions expected during parsing failures.  I'll try to flesh out more 
failure tests and then raise the issue to the WG.  Oracle throws a 
INVALID_STATE_ERR though it isn't a scenarion described in the 
exceptions list, Xerces-J throws a NullPointerException.

>LSInput but actually creates one, effectively doing the same thing as
>DOMBuilderTest6.
>  
>

Removed the extraneous createLSInput.

>DOMEntityResolverTest1: assumes external entities are actually resolved.
>Should add a 'validating' implementationAttribute.
>
>  
>
Done.

>DOMImplementationLSTest1: has a hasFeature 'temporarily commented out' that
>should probably be put back in.
>
>  
>
The earlier version of Oracle that I've been using doesn't return true, 
though it appears to support async loading.  Since it is my only 
available implementation with any support for asych loading, commenting 
out the hasFeature allows me to actually run the body of the test.

>DOMImplementationLSTest3: assumes the implementation supports schemas. This
>is not required. Could raise NOT_SUPPORTED_ERR.
>
Done.

>DOMInputSourceTest3: invalid. Document.inputEncoding should not be affected
>by the original LSInput.encoding unless a byteStream was used.
>  
>
The spec is explicit that LSInput.encoding should be ignored.  I've 
split the test into two parts (3 and 6), one for characterStreams and 
one for strings, since ECMAScript bindings don't support character 
streams.  LSInput.encoding is set to UTF-8 but document.inputEncoding is 
expected to be 'UTF-16'.

>DOMWriterFilterTest0: acceptNode's parameter should be 'nodeArg', no longer
>'n'. (does this require fiddling with TSML?)
>  
>
LSSerializerFilter in the candidate recommendation extends NodeFilter in 
traversal.  L2 Traversal's NodeFilter uses n as the parameter name.  Why 
do you think it should be nodeArg.

>DOMWriterFilterTest1: tries to use SHOW_ATTRIBUTE, but this is not declared
>anywhere (should be in &filterVars;). Then tries to test for the acceptance
>of the attr1 node, but this should actually be filtered out according to the
>given LSSerializerFilter: unlike with LSParserFilters, Attribute nodes and the
>document element node are, I believe, supposed to be passed to acceptNode.
>Spec is currently unclear on what happend if a filter declines to be SHOWn
>an element; in Range 2.0's NodeFilter, this would result in a SKIP, not an
>ACCEPT, but I don't now if this is supposed to apply to 3.0 LS too.
>
>DOMWriterFilterTest3: SHOW_COMMENT again not defined in &filterVars;.
>  
>

I've added SHOW_ATTRIBUTE and SHOW_COMMENT to dom3tests.ent.  If they 
had been used outside of an inner class, they would have been detected 
by schema validation.  However, in this case schema validation did not 
catch them and since the inner class extended NodeFilter, Java didn't 
complain either.

Both Xerces-J and XDK pass this test apparaently assuming that if not 
shown an node the response is assumed to be accept.  This seems to be 
the desirable interpretation, but if you don't think the spec is 
explicit enough, please raise it as an issue in the spec.

>CharacterStream1, SystemId1: tries to create an LSParser with mode 0. No such
>mode, should be 1.
>  
>

Done.

>LSParserConfig6: the description gives the wrong parameter name, it is in fact
>testing infoset. However, it tests to see whether you can directly set it to
>false - which should have no effect. To test it with a false value, set one of
>the other parameters it affects to the 'wrong' value.
>  
>
Late night cut and paste.  I've modified the test for infoset's 
peculiarities, please review.

>LSParserConfig7: tries to set namespaces true and then tests it is false. Oop.
>(ah, you noted this one already)
>  
>
Done.

>LSParserConfig8, LSSerializer8: actually tests for xml-declaration instead of
>well-formed
>
>  
>
Comment changed.

>LSSerializerConfig1: xml-declaration should be true by default, not false,
>surely?
>  
>
Done.

>LSSerializerConfig2: normalize-characters is listed twice. So the result will
>be 22, not 23.
>  
>

Done.

>LSSerializerConfig6: ignore-unknown-character-denormalizations shoud be true
>by default, not false. The canSet test and the values in the
>assertDOMException are hence also the wrong way around.
>
>  
>
Done.

>----
>
>And here are the test results for pxdom 1.0-pre, WITHOUT fixing the tests
>for the above issues. The remaining failures are mostly to do with pxdom's
>lack of support for ResourceResolvers, which are omitted for the moment as
>they're a bit pointless until external entities are fully supported.
>
>PASSED 43 tests
>FAILED 21 tests:
>  DOMBuilderTest3: Assertion nextSibling_after_add failed. Expected elt2, go...
>  DOMBuilderTest4: Assertion previousSibling_after_insert_before failed. Exp...
>  DOMBuilderTest5: Calling setParameter on <pxdom.LSParserConfiguration inst...
>  DOMBuilderTest6: Assertion documentIsNull failed. Got <pxdom.Document inst...
>  DOMBuilderTest7: Assertion throw_ImplementationException failed. Exception...
>  DOMEntityResolverTest1: Assertion count_elt1_before_applying_entity_resolv...
>  DOMImplementationLSTest1: Calling createLSParser on <pxdom.DOMImplementati...
>  DOMImplementationLSTest3: Calling createLSParser on <pxdom.DOMImplementati...
>  DOMInputSourceTest3: Assertion encodingstringcheck0 failed. Expected ISO-8...
>  DOMInputSourceTest5: Calling parse on <pxdom.LSParser instance at 0x00BC50...
>  DOMWriterFilterTest1: Calling writeToString on <pxdom.LSSerializer instanc...
>  DOMWriterFilterTest3: Calling writeToString on <pxdom.LSSerializer instanc...
>  CharacterStream1: Calling createLSParser on <pxdom.DOMImplementation insta...
>  SystemId1: Calling createLSParser on <pxdom.DOMImplementation instance at ...
>  LSParserConfig6: Assertion setFalse failed. Got 1
>  LSParserConfig7: Assertion setTrueIsEffective failed. Got 1
>  LSParserConfig8: Assertion canSetFalse failed. Got 1
>  LSSerializerConfig1: Assertion xml-declaration-is-false failed. Got 1
>  LSSerializerConfig2: Assertion definedParameterCount failed. Expected 23, ...
>  LSSerializerConfig6: Assertion defaultValue failed. Got 1
>  LSSerializerConfig8: Assertion canSetFalse failed. Got 1
>
>  
>

Received on Thursday, 18 December 2003 16:07:46 UTC