- From: Curt Arnold <carnold@houston.rr.com>
- Date: Mon, 27 Jan 2003 22:33:34 -0600
- To: jeroen@x-hive.com, www-dom-ts@w3.org
Comments and/or possible constructs inline: Jeroen van Rotterdam wrote: > Curt wrote: > > >>For the load/save tests, I always expected that we would need to add some >>similar test framework implemented classes. However, you are probably > > in >a better position to enumerate the capabilities that you would want. > > Ok, browsing through the spec I believe that the following methods are > required to write certain LS tests: > > > - a method to create a new File OutputStream a.k.a. in java new > FileOutputStream(String fileName) There are a lot of issues involved with letting the tests write to the file system. If writing to the file system is needed, then the temporary filenames should be generated by the framework. However, even these could not be supported by browser based implementations. I'm pretty darn curious about what would be considered a DOMOutputStream on an ECMAScript implementation. You'd want to transparently use an existing browser stream implementation, but it might be good to have a fallback that any class implementing a writeByte(byte) method would also be recognized as a DOMOutputStream. On further thought, it appears that some minimal definition for an recognizable implementation of DOMOutputStream, DOMInputStream and DOMReader is necessary for the ECMAScript test harness to implement those interfaces to support the tests. > - a method to close a DOMOutputStream <close obj="outStream" interface="DOMOutputStream"/> > - a method to create a new File object a.k.a in java: new File(String > filename) See previous > - a method to test the existence of a file See previous > - a method to test whether a substring appears in a file Is this specific to files? > - a method to get the size of a file Ditto. > - a method to create a new FileReader from a File object <var name="reader" type="DOMReader" value=""staff.xml""/> Would there be any need (hopefully not) for this to something other than a resource provided with the test? 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. > - a method to create a new byte array output stream <var name="outStream" type="DOMOutputStream"/> would need something like the writeByte(byte) fallback to implement this in ECMAScript. > - a method to create a new input stream from a URL <var name="inStream" type="DOMInputStream" value="url"/> > - the ability to create a new input stream from an output stream <var name="inStream" type="DOMInputStream"/> ... <assign var="inStream" obj="outStream"/> > - a method to get a substring of DOMString <substringData var="substring" obj="string" offset="1" count="5" interface="DOMString"/> > - A method to create a new input stream from a string variable > I guess we don't need that. DOMInputSource.stringData is meant for that one. Actually, it would provide a mechanism to test DOMInputSource.setByteStream(). <var name="source" type="DOMInputSource"/> <var name="inStream" type="DOMInputStream"/> ... <createDOMInputSource var="source" obj="implementation"/> <assign obj="inStream" value='"<foo/>"'/> <byteStream obj="source" value="inStream"/> Should be functionally equivalent to: <stringData obj="source" value='"<foo/>"'/> but would test a different code path
Received on Monday, 27 January 2003 23:33:42 UTC