xml-dev - Fw: [xml-server] Re: Tools. JPython. SAXON

[Paul Tchistopolskii <paul@qub.com>]

To: <xml-server@egroups.com>
Cc: <xml-dev@ic.ac.uk>
Sent: Sunday, October 24, 1999 3:12 PM
Subject: Re: [xml-server] Re: Tools. JPython. SAXON


> > > My personal interest is to implement the
> > > prototype.
> > 
> > Fine.
> > 
> > > I think I'l use JPython ( the letter in archive
> > > with the Subj: 'JPython' explains why ).
> > > 
> > > Now  I started searching for existing XSLT
> > > implementation which could work on top of DOM,
> > > but not a text file.
> > > 
> > > The XML-server prototype colud read plain XML
> > > files into in-memory DOM and then invoke
> > > 'strored XSLT tranformantions'.
> > > 
> > > JPython means that I am actualy  looking
> > > for Java stuff.
> > > 
> > > I think -  SAXON is a good choice, it is
> > >  XSLT on DOM ( and also much more ;-)
> > > 
> > > http://users.iclway.co.uk/mhkay/saxon/index.html
> > > 
> > > If you know some other Java libs of this kind,
> > > please let me know.
> > > 
> > 
> > What about XSL:P (http://www.clc-marketing.com/xslp/) ?
> > XSL:P is widely used by Cocoon users, and its author, Keith is porting
> > it to C++ to be used by next Netscape's navigator release ?
> 
> Thank you for this one. It looks promizing.  
> 
> Like SAXON., it supports multiple DOM implementations  
> ( at the moment I think that plugging the new DOM into 
> SAXON may be a bit easier. I need to check )
> 
> Ability to plug diferent components is one of the 
> requirments. I like SAX because it allows me 
> to change the parsers when I find that some parser 
> is weaker than I need.
> 
> Is there any effort to get a "SAX for DOM" ?  I mean 
> that it appears that at the moment SAXON and and XSL:P 
> are using different ways for plugin the DOM components, 
> or maybe I'm wrong?
>  
> > XT (http://www.jclark.com/xml/xt.html) is fast and in sync with the
> > latest recommendations, but isn't implementing a standard DOM.
> 
> Yes. I don't think I could use it, even I realy like  XT ;-)... 
> It appears that we need XSLT on top of DOM,  but not the 
> XSLT on file *and*  it would be nice to have a DOM as a separate 
> pluggable compoment, because nodoby knows what DOM vendor 
> will be better ;-) ... I think that as many standart components  
> we'l we get  - as better.
> 
> > The Oracle XMLParser 2.0.2.4 implements an integrated
> > XML Parsing engine with built-in XPath support as well
> > as XSLT Proposed Recommendation compliance.
> 
> > All in Java. Good to go at http://technet.oracle.com/tech/xml
> 
> Thank you. Unfortunately I failed to find anything about 
> pluggable DOM support.
> 
> All I have is:
> 
> Features in Oracle's XML Parser for Java v2 
>  Integrated support for W3C XSLT Final Working Draft  
>  Intergrated Document Object Model (DOM) Level 1.0 API 
>  Integrated SAX 1.0  API 
> 
> From this information I don't understand if  there is
> even any support for XSLT on top of DOM in Oracle 
> XML parser.
> 
> Will check.
> 
> Rgds.Paul.
 
 


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/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe 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)