- From: Curt Arnold <carnold@houston.rr.com>
- Date: Thu, 30 Jan 2003 23:46:42 -0600
- To: jeroen@x-hive.com, www-dom-ts@w3.org
Jeroen van Rotterdam wrote:
> Ok, so for the framework you suggest testing DOMWriter using pipes
> by creating an inputstream from an outputstream ?
>
> I guess I can live with that.
I don't know if we can do much more than check that the same DOM
implementation can read the stream back.
>>- a method to get the size of a file
>
>
> This is typically used to do weak tests on e.g. pretty print. Since pretty
> print is weakly defined you would probably fall back to test whether the
> output has a different size than the input after applying pretty-print.
> I know this isn't great but it's probably the best you can do.
Being able to get a count of the number of times a specific character
appeared in a stream might be helpful. If you output 100 elements and
the pretty printed stream has no linefeeds, you'd know it wasn't very
pretty.
>
> If we use strings and read from the outputstream I can do it with
> String.length().
>
>
>>Would there be any need (hopefully not) for this to something other than
>>a resource provided with the test?
>
> No, DOMInputSource can have both a DOMInputStream as a DOMReader as an input.
I was trying to distinguish between reading files that were provided as
part of the test package (like "staff.xml") versus arbitrary file system
files.
>>Do we want to provide a mechanism to mechanism to create a reader from a
>>file? It would be difficult to implement for ECMAScript. It might be
>>cleaner just to provide a mechanism to initialize a reader from a string.
>
>
> If we just use strings in tests we won't be able to test System
> Exceptions. It is currently still an open issue whether System Exceptions
> are passed on and how. If this will be done by a DOMException than it
> makes sense to build a test for it (something like parse a non existing
> file and find out whether a DOMException is thrown).
Populating a character reader from a file would be difficult from
JavaScript. However, it should be possible to fill a stock reader
implementation from a string and allow a test to provide a custom reader
that throws an exception from both Java and JavaScript implementations
of DOM.
<var name="myFlakyReader" type="DOMReader">
<read>
<throw/>
</read>
</var>
or
<var name="myStringReader" type="DOMReader" value="<?xml
version='1.0'?><foo/>"/>
Received on Friday, 31 January 2003 00:46:48 UTC