Default Namespace in XPath

To access the different nodes within the cosmos with an XPath I use an XPath processor. Unfortunatly XPath 1.0 does not allow to specify the default namespace. To distinguish cosmos object nodes from other, more general content within the objects I like to put them into a specific namespace. So either all the IDs (tag names) of the cosmos objects need to be prefixed (eg. 'c:livcos.org/c:test/c:TestDocument' or we are restricted to XPath 2.0, which allows to specify the default namespace.
Since JAXP 1.3 only offers XPath 1.0 this implemention becomes dependent on the processor implementaion (Saxon 8.6.1B for now). The default namespace can be set with net.sf.saxon.xpath.StandaloneContext.setDefaultElementNamespace().

XSLT read on demand

With the prototype org.livcos.prototype.xslt.read_on_demand we test different XSLT processors about which elements are read from the source for a transformation. We transform a subnode with a stylesheet only matching certain elements.

Report:

• Xalan reads the complete tree rooting at the source node.
• Saxon reads the owner document of the source node.
• Saxon ignores unneeded parts of the tree.
• XT handles only Stream- and SAXSources. The later are streamed into the internal object model completely.
• Oracle XDK handles Stream- and SAXSources.
• Oracle XDK handles DOMSources only with their properitary object model.
• The Oracle XDK object model is based on abstract classes, therefore a customized implementation needs to be build on top of it.

With all the processors reading only the tree below the source node, only the Saxon Processor would reduce the amount of data being read, by ignoring the parts not matched in the stylesheet.
A DOM-to-SAX event producer allows to feed a copy in the internal format of the individual processors object model.

Cosmos Nodes

The simplicity of the all-nodes approach has lead me to give it a try. All the objects within the cosmos can be accessed by a simple XPath. For XSLT transformations the sources can be also specified by an XPath. Being aware of the huge dimension of the entire cosmos this should allow to specify the smaller parts a working context is interested in.

Cosmos Basic Structure

I'm working on a cosmos-domain-container-entity hierarchy to implement the first cosmos object model. Entities offer an XML interface for read and modification access and serve as a kind of XML document.
A friend of mine is working on the JSR-170 specification and has planted the idea of a cosmos being a huge, virtual node-tree. There are just nodes and only one document, the cosmos itself.

Intro

This blog captures thoughts to the LivCos project.