Lists Home |
Date Index |
- From: Tyler Baker <email@example.com>
- To: Juergen Modre <firstname.lastname@example.org>
- Date: Tue, 24 Feb 1998 10:07:24 -0500
Juergen Modre wrote:
> David Megginson wrote:
> > After considering the various discussions over the past few weeks, I
> > propose that we make the following changes:
> > 1) Add a parse() method that accepts a stream.
> Fully agree.
> > 2) Add a parse() method that accepts a character buffer.
> I have similar thoughts like James and therefore don't really see the need for it.
> For the case to parse parts from an larger document the char can always be
> converted to an InputStream to be used with 1).
> But maybe your intention goes into another direction.
One way to get around the char array problem is to sort of have a feeder mechanism in
which you continually feed the parser a set of bytes like in the case of an input stream
except that you explicitly turn the parser on before feeding that parser the data and
explicitly turn the parser off when you are done feeding it.
For example you could have methods that looked like this:
Then you could just go through a loop and feed in a character array you populate with the
document data until you are finished. This of course would be much more straightforward
with an input stream, however this would get around the problem of languages which have no
concept of input streams.
The biggest problem I see with this suggestion is that it will make writing parsers a bit
more difficult to implement since you have to essentially freeze your parser's state after
each call to parseBuffer() finishes.
Just a suggestion,
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)