[
Lists Home |
Date Index |
Thread Index
]
Michael Brennan wrote:
> Well, I'm unemployed and not getting any job offers, so I'm using my
> free time to pull together some disparate snippets of code -- and
> working on some new stuff -- packaging it up and making it available as
> open source.
>
Thanks Michael for your ideas...
I have some observations on your approach, maybe some improvements, too:
- The fact that the package is not designed as a set of interfaces,
makes it difficult to adopt the same paradigm for something different
then SAX callbacks.
For example, a program that do something usefull with XML, like counting
the tags :->.
My application writes XML programmatically with SWAN-output and I would
like just to change / attach / derive a piece of code that computes the
result.
Now, In order to do this, I must have a complete new implementation of
the class hierarchy. (Correct me if I am wrong)...
The computation could be of course something interesting, like an
XSLT-like transformation limited to the child:: and attribute:: axis.
- If SWAN-output was an interface, let's say, a protocol, we could have
bridges between SAX an SWAN. That is, a class that takes a SAX flow and
produces the set of "SWAN" callbacks accordingly.
Many applications would be easier to write "in SWAN". The rest of the
system that produces the XML (programmatical output, SAX-SWAN bridges)
would not change, only the front-end would.
In few words: the SAX output seems to me just be an implementation of
your paradigm.
Enzo Maggi
-- Enzo Maggi enzo.maggi@expway.fr
senior research engineer - Expway
|
