xml-dev - C-SAX-AN ?

[Paul Tchistopolskii <paul@qub.com>]

Hello.

I have some idea. 

PART 1.

Before explaining the idea itself I have to provide a few details 
about  CPAN ( Comprehensive Perl Archive Network). 
http://www.perl.com/CPAN-local/README.html
Those who already know what  is CPAN could skip to PART 2.

CPAN ( Simplified ).

CPAN contains hundreds of perl modules. Most of reasonable 
perl modules are wrappers around some C library. 
Marshalling data between the wrapper ( written in perl ) and 
the proprietary library ( written in C ) is done with some standard
perl API,called XS. XS is set of functions, written in C.

PART 2.

It is possible ( and I think it is also reasonable )  to take  
the design pattern similar to this one which is used by 
perl modules and to use it with SAX.

Let me explain it with 3 examples.

Example  A.

"Directory to XML".   Many people need to  scan directory  and then 
turn the contents into XML and then use XSL to process it, for example. 
The simplest solution is to write a perl script  which will produce the 
XML file. The drawback of this solution is that the produced XML 
file should be then again parsed with XML parser ( and XML parsing 
is relatively time-consuming operation ). The 'ideal' solution could be 
to have Dir2XML be a Java component providing a correct stream 
of SAX events. 

Example B.

"DTD to XML". The same but a bit more complex ( and more 
interesting ) usecase.  There is already some DTDParser 
( http://xmlhack.com/read.php?item=626 )

It is a nice analogy of  'proprietary library written in C' ;-)

To use this DTD parser  in  Ux ( http://www.pault.com/Ux/ )
I have to write a simple Java wrapper around this 
component. The wrapper will first use the 'proprietary
API' to read the DTD into 'proprietary data structures'. 
Then wrapper will generate the stream of SAX events 
out of that proprietary data structure. 

This wrapper very much looks to me like it is some 
'perl module between  proprietary C library and 
my SAX-based code'.

This allows me to use DTDparser as if it was 
SAX parser  right from the beginning.

Example C.

"SQL to XML", "CSV to XML" e t.c e t.c.  the same stuff. 

Conclusion 1.

If you write your  "Some 2 XML"  component to be 
a provider of stream of SAX events - you are simplifying 
things for  some people  who will try to use that 
component.

Conclusion 2.

If you don't write your  "Some 2 XML"  component
in this way - this is also not a big deal  IF there exists 
something like CPAN where SAX hackers are sharing 
the wrappers they write around 'proprietary components'.

Conclusion 3.

The same could be done with XML 2 Some  - but this 
is a bit harder.

PART 3.

This year I'll anyway write some  SAX-based 
Some 2 XML modules, because this is a core feature of  
Ux  design. 

I think  Cocoon is also based on something similar, 
estimating that  there will be some number of components 
generating streams of SAX events.


Final Conclusion 

If this all looks reasonable to you 
and / or  if you already have some opensource SAX - generator / SAX - acceptor
and /or you are in any way interested in creating such a network, 
or you know somebody who already  created the network  described above - 

please write me to  paul@pault.com

Rgds.Paul.

PS. 
Maybe 4xt.org  could be used for such a network ?