InputFactory:
As discussed with Santiago (see below), when the input is a XML file in
the form of a java.io.Reader, InputFactory will convert it into FI
format before it can return a stream reader. I've added a "convert"
method in tool XML_SAX_FI to transform the xml file into an
OutputStream. In the InputFactory, the createXMLStreamReader method will
use a PipedOutputStream to call this method
(XML_SAX_FI->convert(xml,outputStream)). This is to avoid writing the
resulting FI doc out to the file system. The OutputStream will then be
used to create a PipedInputStream which will be used to create a stream
reader StAXDocumentParser(inputStream, manager) (*for this new
constructor, pls see the next email).
Frankly, I'm not familiar with Piped streams, only know it
conceptually. Will need to test it out. Initially, I thought about
writing out temporary FI files, but believed the piped streams would be
better.
Joe
Santiago Pericas-Geertsen wrote:
>
> On Jan 6, 2005, at 2:49 PM, huizhe wang wrote:
>
>> Santiago Pericas-Geertsen wrote:
>>
>>>
>>> On Jan 6, 2005, at 1:32 PM, huizhe wang wrote:
>>>
>>>> public final String filesDir = "./lib/files";
>>>> protected XMLInputFactory factory;
>>>> ...
>>>> input = new File(filesDir, args[0] + ".xml");
>>>> master = new File(filesDir, args[0] + ".stream");
>>>>
>>>> XMLStreamReader r1 =
>>>> factory.createXMLStreamReader(new java.io.FileReader(input));
>>>> XMLStreamReader r2 =
>>>> new XMLStreamPlayer(new java.io.FileReader(master));
>>>> Util util = new Util();
>>>> if(r1 == null)
>>>> result = Status.failed("Reader is null");
>>>> EqualityResult r = util.equals(r1,r2);
>>>>
>> The TCK comes with a list of XML files. I believe the framework
>> (tck.jar) finds these files and feed the tests with files names using
>> args. The test then creates XMLStreamReader using xml files. r2 in
>> the code above is a stream reader instance of BEA's stream reader
>> implementation.
>
>
> From the extension, it seems as if r2 is actually reading a non-xml
> file, right? Is it a binary file? This may be what they called
> TokenStream.
>
>> util.equals(r1,r2) iterates and compare r1.next with r2.next.
>
>
> Right.
>
>> So for us to get pass this particular test, we would have to: convert
>> the xml file to fint, replace the original xml file with the fint to
>> trick the test (think this is allowed :-)
>
>
> Yes, perhaps what you could do is: create a special reader factory
> whose readers transcode XML into FI as first step (e.g. into a byte
> array) and then read the binary representation. That way you don't
> need to modify the TCK, I think.
>
>> , but more importantly, the xml->fint must be perfect otherwise
>> r1.next won't neccessarily return the same element as r2.next.
>
>
> Right, and hopefully that works :) Note that Paul has committed code
> (and utility commands) to convert between the various XML flavors.
>
> Makes sense?
>
> -- Santiago
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_fi.dev.java.net
For additional commands, e-mail: dev-help_at_fi.dev.java.net