All Packages from org.apache.xml.dtm.ref.dom2dtm.* to org.apache.xml.dtm.ref.sax2dtm.*

Home >> All >> org >> apache >> xml >> dtm >> [ ref Javadoc ]

•

• org.apache.xml.dtm.ref: Javadoc index of package org.apache.xml.dtm.ref.

Package Samples:

• org.apache.xml.dtm.ref.sax2dtm
• org.apache.xml.dtm.ref.dom2dtm

Classes:

• CoroutineManager: Support the coroutine design pattern. A coroutine set is a very simple cooperative non-preemptive multitasking model, where the switch from one task to another is performed via an explicit request. Coroutines interact according to the following rules: One coroutine in the set has control, which it retains until it either exits or resumes another coroutine. A coroutine is activated when it is resumed by some other coroutine for the first time. An active coroutine that gives up control by resuming another in the set retains its context -- including call stack and local variables -- so that if/when ...
• SAX2DTM2: SAX2DTM2 is an optimized version of SAX2DTM which is used in non-incremental situation. It is used as the super class of the XSLTC SAXImpl. Many of the interfaces in SAX2DTM and DTMDefaultBase are overridden in SAX2DTM2 in order to allow fast, efficient access to the DTM model. Some nested iterators in DTMDefaultBaseIterators are also overridden in SAX2DTM2 for performance reasons. Performance is the biggest consideration in the design of SAX2DTM2. To make the code most efficient, the incremental support is dropped in SAX2DTM2, which means that you should not use it in incremental situation. To ...
• SAX2RTFDTM: This is a subclass of SAX2DTM which has been modified to meet the needs of Result Tree Frameworks (RTFs). The differences are: 1) Multiple XML trees may be appended to the single DTM. This means that the root node of each document is _not_ node 0. Some code has had to be deoptimized to support this mode of operation, and an explicit mechanism for obtaining the Node Handle of the root node has been provided. 2) A stack of these documents is maintained, allowing us to "tail-prune" the most recently added trees off the end of the DTM as stylesheet elements (and thus variable contexts) are exited. ...
• DTMStringPool: DTMStringPool is an "interning" mechanism for strings. It will create a stable 1:1 mapping between a set of string values and a set of integer index values, so the integers can be used to reliably and uniquely identify (and when necessary retrieve) the strings. Design Priorities: String-to-index lookup speed is critical. Index-to-String lookup speed is slightly less so. Threadsafety is not guaranteed at this level. Enforce that in the application if needed. Storage efficiency is an issue but not a huge one. It is expected that string pools won't exceed about 2000 entries. Implementation detail: ...
• IncrementalSAXSource_Filter: IncrementalSAXSource_Filter implements IncrementalSAXSource, using a standard SAX2 event source as its input and parcelling out those events gradually in reponse to deliverMoreNodes() requests. Output from the filter will be passed along to a SAX handler registered as our listener, but those callbacks will pass through a counting stage which periodically yields control back to the controller coroutine. %REVIEW%: This filter is not currenly intended to be reusable for parsing additional streams/documents. We may want to consider making it resettable at some point in the future. But it's a small ...
• DTMDocumentImpl: This is the implementation of the DTM document interface. It receives requests from an XML content handler similar to that of an XML DOM or SAX parser to store information from the xml document in an array based dtm table structure. This informtion is used later for document navigation, query, and SAX event dispatch functions. The DTM can also be used directly as a document composition model for an application. The requests received are: initiating DTM to set the doc handle resetting DTM for data structure reuse hinting the end of document to adjust the end of data structure pointers createnodes ...
• DTMAxisIterNodeList: DTMAxisNodeList gives us an implementation of the DOM's NodeList interface wrapped around a DTM Iterator. The author considers this something of an abominations, since NodeList was not intended to be a general purpose "list of nodes" API and is generally considered by the DOM WG to have be a mistake... but I'm told that some of the XPath/XSLT folks say they must have this solution. Please note that this is not necessarily equivlaent to a DOM NodeList operating over the same document. In particular: If there are several Text nodes in logical succession (ie, across CDATASection and EntityReference ...
• DTMChildIterNodeList: DTMNodeList gives us an implementation of the DOM's NodeList interface wrapped around a DTM Iterator. The author considers this something of an abominations, since NodeList was not intended to be a general purpose "list of nodes" API and is generally considered by the DOM WG to have be a mistake... but I'm told that some of the XPath/XSLT folks say they must have this solution. Please note that this is not necessarily equivlaent to a DOM NodeList operating over the same document. In particular: If there are several Text nodes in logical succession (ie, across CDATASection and EntityReference boundaries), ...
• DTMNodeListBase: DTMNodeList gives us an implementation of the DOM's NodeList interface wrapped around a DTM Iterator. The author considers this something of an abominations, since NodeList was not intended to be a general purpose "list of nodes" API and is generally considered by the DOM WG to have be a mistake... but I'm told that some of the XPath/XSLT folks say they must have this solution. Please note that this is not necessarily equivlaent to a DOM NodeList operating over the same document. In particular: If there are several Text nodes in logical succession (ie, across CDATASection and EntityReference boundaries), ...
• DTMNodeList: DTMNodeList gives us an implementation of the DOM's NodeList interface wrapped around a DTM Iterator. The author considers this something of an abominations, since NodeList was not intended to be a general purpose "list of nodes" API and is generally considered by the DOM WG to have be a mistake... but I'm told that some of the XPath/XSLT folks say they must have this solution. Please note that this is not necessarily equivlaent to a DOM NodeList operating over the same document. In particular: If there are several Text nodes in logical succession (ie, across CDATASection and EntityReference boundaries), ...
• DTMNodeIterator: DTMNodeIterator gives us an implementation of the DTMNodeIterator which returns DOM nodes. Please note that this is not necessarily equivlaent to a DOM NodeIterator operating over the same document. In particular: If there are several Text nodes in logical succession (ie, across CDATASection and EntityReference boundaries), we will return only the first; the caller is responsible for stepping through them. (%REVIEW% Provide a convenience routine here to assist, pending proposed DOM Level 3 getAdjacentText() operation?) Since the whole XPath/XSLT architecture assumes that the source document is ...
• CustomStringPool: CustomStringPool is an example of appliction provided data structure for a DTM implementation to hold symbol references, e.g. elelment names. It will follow the DTMDStringPool interface and use two simple methods indexToString(int i) and stringToIndex(Sring s) to map between a set of string values and a set of integer index values. Therefore, an application may improve DTM processing speed by substituting the DTM symbol resolution tables with application specific quick symbol resolution tables. %REVIEW% The only difference between this an DTMStringPool seems to be that it uses a java.lang.Hashtable ...
• DTMManagerDefault: The default implementation for the DTMManager. %REVIEW% There is currently a reentrancy issue, since the finalizer for XRTreeFrag (which runs in the GC thread) wants to call DTMManager.release(), and may do so at the same time that the main transformation thread is accessing the manager. Our current solution is to make most of the manager's methods synchronized . Early tests suggest that doing so is not causing a significant performance hit in Xalan. However, it should be noted that there is a possible alternative solution: rewrite release() so it merely posts a request for release onto a threadsafe ...
• DOM2DTMdefaultNamespaceDeclarationNode: This is a kluge to let us shove a declaration for xml: into the DOM2DTM model. Basically, it creates a proxy node in DOM space to carry the additional information. This is _NOT_ a full DOM implementation, and shouldn't be one since it sits alongside the DOM rather than becoming part of the DOM model. (This used to be an internal class within DOM2DTM. Moved out because I need to perform an instanceof operation on it to support a temporary workaround in DTMManagerDefault.) %REVIEW% What if the DOM2DTM was built around a DocumentFragment and there isn't a single root element? I think this fails that ...
• ChunkedIntArray: ChunkedIntArray is an extensible array of blocks of integers. (I'd consider Vector, but it's unable to handle integers except by turning them into Objects.) Making this a separate class means some call-and-return overhead. But doing it all inline tends to be fragile and expensive in coder time, not to mention driving up code size. If you want to inline it, feel free. The Java text suggest that private and Final methods may be inlined, and one can argue that this beast need not be made subclassable... %REVIEW% This has strong conceptual overlap with the IntVector class. It would probably be a good ...
• DTMNamedNodeMap: DTMNamedNodeMap is a quickie (as opposed to quick) implementation of the DOM's NamedNodeMap interface, intended to support DTMProxy's getAttributes() call. ***** Note: this does _not_ current attempt to cache any of the data; if you ask for attribute 27 and then 28, you'll have to rescan the first 27. It should probably at least keep track of the last one retrieved, and possibly buffer the whole array. ***** Also note that there's no fastpath for the by-name query; we search linearly until we find it or fail to find it. Again, that could be optimized at some cost in object creation/storage.
• ObjectFactory: This class is duplicated for each JAXP subpackage so keep it in sync. It is package private and therefore is not exposed as part of the JAXP API. This code is designed to implement the JAXP 1.1 spec pluggability feature and is designed to run on JDK version 1.1 and later, and to compile on JDK 1.2 and onward. The code also runs both as part of an unbundled jar file and when bundled as part of the JDK. This class was moved from the javax.xml.parsers.ObjectFactory class and modified to be used as a general utility for creating objects dynamically.
• ExpandedNameTable: This is a default implementation of a table that manages mappings from expanded names to expandedNameIDs. %OPT% The performance of the getExpandedTypeID() method is very important to DTM building. To get the best performance out of this class, we implement a simple hash algorithm directly into this class, instead of using the inefficient java.util.Hashtable. The code for the get and put operations are combined in getExpandedTypeID() method to share the same hash calculation code. We only need to implement the rehash() interface which is used to expand the hash table.
• CoroutineParser: CoroutineParser is an API for parser threads that operate as coroutines. See CoroutineSAXParser and CoroutineSAXParser_Xerces for examples. <grumble> I'd like the interface to require a specific form for either the base constructor or a static factory method. Java doesn't allow us to specify either, so I'll just document them here: public CoroutineParser(CoroutineManager co, int appCoroutine); public CoroutineParser createCoroutineParser(CoroutineManager co, int appCoroutine); </grumble>
• DOM2DTM: The DOM2DTM class serves up a DOM's contents via the DTM API. Note that it doesn't necessarily represent a full Document tree. You can wrap a DOM2DTM around a specific node and its subtree and the right things should happen. (I don't _think_ we currently support DocumentFrgment nodes as roots, though that might be worth considering.) Note too that we do not currently attempt to track document mutation. If you alter the DOM after wrapping DOM2DTM around it, all bets are off.
• DTMNodeProxy: DTMNodeProxy presents a DOM Node API front-end to the DTM model. It does _not_ attempt to address the "node identity" question; no effort is made to prevent the creation of multiple proxies referring to a single DTM node. Users can create a mechanism for managing this, or relinquish the use of "==" and use the .sameNodeAs() mechanism, which is under consideration for future versions of the DOM. DTMNodeProxy may be subclassed further to present specific DOM node types.
• IncrementalSAXSource: IncrementalSAXSource is an API that delivers a small number of SAX events each time a request is made from a "controller" coroutine. See IncrementalSAXFilter and IncrementalSAXFilter_Xerces for examples. Note that interaction is via the deliverMoreNodes method, and therefore coroutine support is not exposed here.
• DTMDefaultBaseTraversers: This class implements the traversers for DTMDefaultBase. PLEASE NOTE that the public interface for all traversers should be in terms of DTM Node Handles... but they may use the internal node identity indices within their logic, for efficiency's sake. Be very careful to avoid confusing these when maintaining this code.
• IncrementalSAXSource_Xerces: IncrementalSAXSource_Xerces takes advantage of the fact that Xerces1 incremental mode is already a coroutine of sorts, and just wraps our IncrementalSAXSource API around it. Usage example: See main(). Status: Passes simple main() unit-test. NEEDS JAVADOC.
• DTMSafeStringPool: Like DTMStringPool, but threadsafe. It's been proposed that DTMs share their string pool(s); that raises threadsafety issues which this addresses. Of course performance is inferior to that of the bare-bones version. Status: Passed basic test in main().

Home | Contact Us | Privacy Policy | Terms of Service