cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: [XalanJ2] org.apache.trax interfaces will be removed tomorrow
Date Wed, 01 Nov 2000 17:03:18 GMT

If i get the new sources from cvs xml-xalan now, will i be able to move C2 to the new interfaces?
(build and run C2) Or should we wait till tomorrow?


--- wrote:
> James Davidson, Rajiv Mordani, and myself got together last week at
> ApacheCon London to work on the TrAX proposal.  As I begin to try and
> implement the javax.xml.trax interfaces, it has become quickly apparent
> that I can't make the two interfaces live side-by-side.  Thus, I'm going to
> make a hard jump from one to the other.  I'm working on the implementation
> today, and should be ready to check in tomorrow.  Sorry for yet another
> churn, but this is really necessary, and will end up being extremely
> beneficial to all.
> The javax.xml.trax interfaces have already been checked into the XalanJ2
> CVS tree.
> The highlights of the changes are:
> 1) Processor has been renamed to TransformerFactory, in order to match the
> javax.xml.parsers pattern.
> 2) Input and Result are defined with abstract interfaces (Source and
> Result) that are empty.  You must use a concrete implementation of these
> interfaces.
> 3) Three subpackages are defined: sax, dom, and stream. These implement the
> specifics for the given Source and Result types.  In addition, the sax
> package has a SAXTransformerFactory, SerializerHandler, and
> TransformerHandler.
> 4) The serializer package is gone (sorry, Assaf).  Instead,
> TransformerFactory now implements a newTransformer method that takes no
> arguments.  This method is defined to return a Transformer that does an
> identity copy from Source to Result.  With this, you can do everything the
> serializer interface did, and more.
> 5) The one thing I don't like much, is that TransformerFactory.newInstance
> no longer takes a string as an argument (which signified the type of
> TransformerFactory you want).  James used the same argument about this as
> he used about the DOM builder.  But, there are complicating factors, and
> it's better to be more simple now, and add this in later, if it is really
> needed.
> 6) The Features class contains URLs for all the supported types of
> features, i.e. DOM, SAX, etc.
> 7) Namespaced names (or Universal Names) are specified to be passed as
> {url}local-name.  While this is ugly, it's the only way to cleanly use
> existing Java classes like Properties that use the String class, and is
> easy enough to parse.  These are used both for output properties, and for
> variables.
> I am pretty happy with this API at this point, though I'm sure it needs
> some polishing on details.  It lines up cleanly with the existing JSR63
> transform stuff (a lot of the wording won't have to be changed), allows
> anybody to define a transformation from any object to any object (for
> instance, it will be easy to define a JDOM transformer),  supports
> different transformer models, is very powerful, yet is relatively simple
> for the job to be done.  I *think* Mike Kay will be pleased also, but he'll
> have to speak for himself.
> -scott

Davanum Srinivas, JNI-FAQ Manager

Do You Yahoo!?
View raw message