Re: DOMOutputStream

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/>"/>