Re: DOM Level 3 LS test results

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

Great! Thanks for the swift fixes.

(Incidentally: have updated Python domts package to handle the append-item
change and a few others - http://www.doxdesk.com/file/software/py/domts.zip)

> I've fixed the thirdElt problem and stripped test2.xml of whitespace and 
> the XML declaration.

I'm still seeing whitespace - a newline at the end. Probably CVS has done
this. (Would require a checkin-as-binary to fix?)

> The underscores are in the names of the local variables that contain the 
> string values.

D'oh. Excuse my foolishness!

> loading a file from the file system, even if its extension is .pdf should
> not be sufficient.

Well... it might be, on a filesystem that stores media type info in metadata
(Mac OS does doesn't it?). Whether the extension could be said to constitute
such metadata on its own is another issue. Anyway, I agree it's probably not
something TS should be relying on.

> I've put in a temporary http://localhost URL.

Yep. Possibly a variant of createTempHttpURI could be created for this
eventuality, eg. <createTempHttpURI method="get"> (as opposed to "put" for
the write-to-URI test)?

> none of my available implementations can get far enough to fail due to
> its absense.

SystemId2 works fine for me.

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

Agree, thanks.

> LSInput.encoding is set to UTF-8 but document.inputEncoding is 
> expected to be 'UTF-16'.

Hmm. Not sure about this, should a string be considered to have an encoding
at all? A bit tricky for Python because although DOMString is 16-bit, it is
bound to native string types, which could equally be 8-bit (in which case
the encoding would be 'us-ascii'), or 32-bit (in which case it is 'utf-32').

(In practical terms, setting document.inputEncoding when creating a document
from a string would mean that it would default to being saved as UTF-16
instead of the usual UTF-8. Not sure this is desirable, but again the spec
should really clarify.)

> LSSerializerFilter in the candidate recommendation extends NodeFilter in 
> traversal.  L2 Traversal's NodeFilter uses n as the parameter name.

Ah. You're right: only LSSerializerFilter inherits from NodeFilter, LSParser
doesn't, which is why the argument names can be different. Oops.

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

Have done already, yes. I would agree that Accept is the intuitive answer,
and for the moment pxdom also exhibits this behaviour. However this runs
counter to the established behaviour of NodeFilter. hmm.

> I've modified the test for infoset's peculiarities, please review.

Looks correct and works for me.

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

OK, if these really are meaning to test for xml-declaration, the canSetFalse
tests should be assertTrues instead of false (which would make sense for
well-formed).

cheers,

-- 
Andrew Clover
mailto:and@doxdesk.com
http://www.doxdesk.com/

Received on Friday, 19 December 2003 08:26:15 UTC