[XalanJ2] org.apache.trax interfaces will be removed tomorrow

[Sc...@lotus.com]

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