W3C home > Mailing lists > Public > www-dom-ts@w3.org > January 2003

Re: DOMOutputStream

From: Curt Arnold <carnold@houston.rr.com>
Date: Thu, 30 Jan 2003 23:46:42 -0600
Message-ID: <3E3A0DC2.6000205@houston.rr.com>
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 

> 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 

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


<var name="myStringReader" type="DOMReader" value="<?xml 
Received on Friday, 31 January 2003 00:46:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:06 UTC