xml-dev - Stream-based SAX and other issues

["Don Park" <donpark@quake.net>]

> can SAX be used to work with 'sysin' input? At present (rightly)
>everything is in terms of java.net.URL or the equivalent SysIDs. However it
>is possible that we may come across chunks of 'raw' XML being emitted by
>tools which don't have a URL address, like (UNIX-like):
> ls | ls2xml | mysaxapp
>(where ls2xml is a fictitious tool that takes the output of ls and emits WF
>XML and  mysaxapp is an XML application that takes XML and (say) draws a
>GUI representation of it.

This is very interesting.  Recently, I had to face the exact opposite of
this issue while adding JAF (Java Activation Framework) support in my app.
Basically, JAF allows mapping between MIME/File types and 'commands' so that
applications can view/edit/dice just about any data given its MIME type:
instantiate MIME handler and drop it into the viewer if it is a GUI
component.  The problem was that commands dealt with only streams so that
commands can act upon only one stream of data and not on multi-stream data.
For example, my HTML didn't know how to find images and my XML viewer
couldn't read the DTDs.  The solution I worked out with JavaSoft is not very
appealing but practical.  Data source context information (i.e. base URL)
are obtained by casting up (instanceof mambo).

For SAX, I think we need to model the data source so that we can do the same
and provide File and URL data source implementations in SAX.  BTW, W3C DOM
provides DocumentContext interface for applications to retrieve data source
infomation (well, there aren't any methods yet, but I hear it is on the
way).

> - is it still possible to process non-SAX events from Lark, AElfred, etc.
>Does one hack LarkDriver, etc? [This may be trivially obvious when I get
>that far...]


Yes, it is possible but its quite messy.  SaxDocumentParser (probably should
be renamed to SaxDocumentManager), just takes a driver class name along with
a URL and returns a DocumentContext object.  In order for SAXDOM to handle
each driver specially, I could add a 'driver-driver' (i.e. your significant
other sitting on the passenger side and telling you how to drive) so that
each driver is automatically mapped to a DriverHandler interface.  Given
that each DriverHandler is driver specific, they can do whatever they want
with the underlying driver implementation.

Don Park

BTW, I forgot to mention in my SAXDOM announcement that SAXDOM has been
tested with AElfred and MSXML SAX drivers.  It works great.  Great job,
David!

I am planning to put together a JavaScript-based demo for SAXDOM similar to
MSXML demos.  It will be interesting!  SAXDOM documentation (the source code
;-) will be improved sometime after that.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)