[Proposal] DTM separation work

[mk...@ca.ibm.com]

Hi, All

Here I would like to propose a change to separate the DTM classes (classes
under org.apache.xml) from Xalan and XPath. Before going into the details
of this change, it is better to review the current status first.

The Xalan classes are organized into three different layers with package
names org.apache.xalan, org.apache.xpath and org.apache.xml. The package
org.apache.xml is meant to be in the lowest level. It contains the DTM
implementation and common xml utility classes. Currently some classes under
org.apache.xml have dependencies on classes in org.apache.xalan and
org.apache.xpath. As an example, you can find the following line in
org.apache.xml.dtm.ref.sax2dtm.SAX2DTM which reads a value from the Xalan
TransformerFactoryImpl class:

m_useSourceLocationProperty=org.apache.xalan.processor.TransformerFactoryImpl.m_source_location;


The DTM separation work is driven by the following requirements:

1. Currently we cannot build a separate dtm.jar which only contains the
classes under org.apache.xml, because some classes have dependencies on
classes at a higher level.

2. The DTM separation work is a prerequisite for the on-going XPath
separation work, which aims at providing a standalone xpath.jar.

3. DTM separation is required when we move to one jar packaging, i.e. put
both XSLTC and Xalan classes into one big jar. If we don't do this, we will
lose the capability of building the jar with Sun JDK 1.4.

4. The work in the XSLTC_DTM branch also has a requirement on DTM
separation, if we want to retain the capability of building a standalone
xsltc.jar.

5. The new structure is cleaner and easier to maintained.

Changes by the DTM separation work:

   Three XPath utility classes (DOMHelper, DOM2Helper and DOMOrder) are
   moved from org.apache.xpath to org.apache.xml.utils. They are used by a
   few classes in org.apache.xml.utils. They have no dependency on other
   XPath classes. It is logical to move them to the lower level component.
   60 error messages are moved from XSLTErrorResources and
   XPATHErrorResourcse to a new XMLErrorResources class in
   org.apache.xml.res. These error messages are only used by the classes in
   org.apache.xml.
   The class XSLMessages is separated into three classes:
   org.apache.xml.res.XMLMessages, org.apache.xpath.res.XPATHMessages and
   the original org.apache.xalan.res.XSLMessages. XSLMessages extends
   XPATHMessages, which again extends XMLMessages. In the new architecture,
   each class only handles error resources at its own level. The common
   interfaces in the old XSLMessages are moved to XMLMessages, while the
   createXPATHMessage and createXPATHWarning interfaces are moved to
   XPATHMessages.  Because of the inheritance relation, all interfaces in
   XSLMessages still work in the same way as before.
   The inner class ThreadControler in
   org.apache.xalan.transformer.TransformerImpl is moved to a new class
   org.apache.xml.utils.ThreadControllerWrapper, so that it can be used by
   IncrementalSAXSource_Filter. The interface setThreadControler() is also
   moved to the ThreadControllerWrapper class. Other interfaces like
   runTransformerThread() and setTransformerThread() are still kept in
   TransformerImpl.
   A static field m_source_location is added in SAX2DTM. Its setter method
   is called by org.apache.xalan.processor.TransformerFactoryImpl whenever
   the FEATURE_SOURCE_LOCATION attribute is changed.
   Move some of the constants in org.apache.xalan.templates.Constants to a
   new class org.apache.xml.utils.Constants, so that they can be used by
   XPath (probably also by XSLTC in the future).

The users do not need to change anything if they do not use the XPath
internal (and deprecated) utility classes DOMHelper and DOM2Helper.

The main change of the DTM separation work is the restructuring of
messages. There is no performance impact for this work.

If you have any comments or concerns, please post it on the list.

Regards,

Morris Kwan
XSLT Development
IBM Toronto Lab
Tel: (905)413-3729
Email: mkwan@ca.ibm.com

Re: [Proposal] DTM separation work

[Joseph Kesselman <ke...@us.ibm.com>]

Uhm. I'm in the process of anaysing whether we can make DTM strictly an 
internal representation, replacing Node Handles with flyweight "cursor" 
objects, which would encapsulate both node access and document traversal. 
The result ought to be more maintainable, more efficient when wrapped 
around non-DTM data sources, and probably more efficient even when 
accessing DTMs since it'd avoid the overhead of translating between Node 
Handles and Node Indexes.

I'm not immediately sure how that interacts with Morris's proposal. I 
think it may achieve many of the same results via a significantly 
different route, fully encapsulating DTM rather than fully exposing it. If 
we're really going to reconfigure DTM as a back-end representation, there 
may be questions about whether the resulting API would be one we'd *want* 
to expose.

The dtm jarfile is an interesting proposal, but we might want to shelve it 
until we have a more solid proposal for what the cursor-based API would 
look like and how DTM would be changed to better mesh with it.


______________________________________
Joe Kesselman  / IBM Research