- From: Curt Arnold <carnold@houston.rr.com>
- Date: Sun, 28 Dec 2003 23:56:25 -0600
- To: www-dom-ts@w3.org
Sander Bos wrote:
>Hi there,
>
>here are some more issues with tests that I found. Sorry if they are
>duplicates, but I figured the CVS version of saturday that I used would have
>most reported issues removed (plus, it should be easy enough to ignore
>them....):
>
>files/test7.xml:
> has reference to files/text5.xml in it, but that one is in the same
>directory, and named differently (test5.xml).
>
>
test7.xml only loaded in DOMBuilderFilterTest1 which checks that entity,
notation, document, document type and attribute nodes are not passed to
acceptNode. The test does expect the document to be successfully
loaded. test7.xml should be corrected since an implementation is free
to resolve the entity references which would cause the test to fail.
>DOMImplementationLSTest1
> Should be optional test, should test for LS-ASync support before creating
>parser?
>
>
The test has a commented out precondition that hasFeature("LS-Async",
null) == true. It is commented out since the only implementation that I
have access to that even partially supports LS-Async does not return
true on the hasFeature call and if I left the precondition in, I would
never be able to run the test. I'll change it since two people have
mentioned it and find another way that will allow me to actually run the
test on the available implementation.
>DOMInputSourceTest3
> resource resolver should not give back null result, then parser will look
>for 'new_system' file on filesystem.
>
>
Current DOMInputSourceTest3 does not have an resource resolver. Haven't
checked history.
>DOMInputSourceTest6
> <characterStream obj="inputSource" var="myReader" interface="LSInput"/>
> in Java becomes
> myReader = inputSource.getCharacterStream();
> so stream is not set on input (input is empty).
>
>
Will be fixed.
>DOMWriterFilterTest0:
> <getAttribute var="attr1" obj="elt1" name='"attr1"'/>
>discovered during implementation that this does not test whether the whole
>attribute is 'accidentally'
>removed (getAttribute returns empty string for non-existing attributes).
>Since I think most impls are likely to get this wrong at first may be idea
>to add extra check that attr1 is present (but empty), also to distinguish it
>from next test.
>DOMWriterFilterTest1:
> The check at the end should verify that the attribute is now gone, not
>that it is still there as it does now.
>
>
Will review tomorrow.
>SystemId1/SystemId2:
> Parser should be made synchronous, not constant 0. Elena reported that
>these tests were wrong in other ways but they are running for me now (so
>maybe our impl does the wrong thing there?).
>
>
Mode should be 1 not 0. That error slipped by since everything I ran
that test against grossly failed before then.
Elena's issue with the URL returned from createTempFileURI() (which
affects SystemId1) is specific to Windows and possibly specific JDK's.
SystemId2 requires a running HTTP server that allows you to HTTP PUT to
http://localhost:8080/domts/temp/{random integer}.xml. The base URI
should eventually be configurable. However checking the ability to
write to an http URL will always require some appropriately configured
server.
Received on Monday, 29 December 2003 00:56:29 UTC