XObjects

[Jonsm at aol.com]

I've spent some time working on an implementation similar to XObjects using
James Clark's XP code as a starting point. XP implements just the
transformation stage of the XSL proposal.

The basic idea of XT is to take a XML parse event stream in, build a tree from
it, apply the transformation rules, and generate an output event stream. I'm
in the process of making three changes to the code.

1) Make plugable objects for accepting the output event stream (in other
words, a document factory). XT has existing objects for IO stream output,
pretty printed IO stream output, and string based output. The is also a
special factory for building HTML output instead of XML output. Needed because
HTML empty elements are different than XML ones. I've implemented a new one to
support chaining - in order words allowing the output from one XSL sheet to be
efficiently fed into another. 

2) I'm now looking at building one that takes a bindings file and instantiates
objects from the mapping described in the file. One demo idea was to use XSL
to map the input XML to HTML objects and then bind to the Java DhHTML classes
in WFC. The HTML would never be generated as text, the document factory would
directly build the tree out of the Java DhHTML objects. Next I might add an
object for vector graphics or drawing molecules.

3) Transformations in XSL work by building up patterns, matching these
patterns to the input tree, and then executing some actions. The actions
generate events to the output object. I've added the capability to XT to allow
external Java classes to be used as actions. I don't know what the current W3C
position on extensibility for XSL is since it was deferred in the current
draft.

My scheme is very simple:
<xsl:template match="act1">
	<xsl:external javaclass="com.jonsm.actions.testAction">
		<!-- process children if you want -->
	</xsl:external>
</xsl:template>
	
This is my current scheme for chaining and binding, it's not implement yet....

<?xsl xsl="koala1.xsl" output="chain" ?>
<?xsl xsl="koala2.xsl" bind="http://objectmap/map.xml" ?>
Chains together two stylesheets. The second stage uses the built-in document
factory for the app reading the xml file. The bind parameter is passed to this
document factor to specify node bindings.

<?xsl output="http://myfactory/fac.class"  bind="http://objectmap/map.xml" ?>
No stylesheet specified,  implied identity transform
XSL will just pass the input events straight to the output doc factory

<?xsl xsl="koala1.xsl" output="chain" ?>
<?xsl xsl="koala2.xsl" bind="http://objectmap/map1.xml"
bind="http://objectmap/map2.xml" ?>
Binds multiple maps to the default document factory. Repeats of parms ok?

<?xsl xsl="koala2.xsl" output="http://myfactory/fac.class"
bind="http://objectmap/map.xml" ?>
Selects a different document factory instead of the default

Binding files look like:
<binding namespace="http://object's namespace" xmlns="http://www.bind.org">
<bind tag="tagname1" object="http://www.object.com/object1.class"/>
<bind tag="tagname2" object="http://www.object.com/object2.class"/>
<bind tag="tagname3" object="http://www.object.com/object3.class"/>
<bind tag="*" object="http://www.object.com/object.class"/>
<bind comment="*" object="http://www.object.com/comment.class"/>
<bind pi="*" object="http://www.object.com/pi.class"/>
</binding>
If a tagname is not matched in the binding file it binds to the default node
factory for the document factory.
Obviously the external node objects must be closely tied into the Document
Factory. For example if the Document Factory is IE the nodes need to be
derived from DhElement.

<?xsl xsl="koala2.xsl"?>
default document factory with no object mappings

An XSL file would allow:
<?xsl output="xxx" bind="xxxx"?>
select a new document factory or send it some new binding

I'd also like to support schemas at each stage for validity checking...
<?xschema xschema="stage1"?>
<?xsl xsl="koala1.xsl" output="chain" ?>
<?xschema xschema="stage2"?>
<?xsl xsl="koala2.xsl" bind="http://objectmap/map.xml" ?>
<?xschema xschema="stage3"?>

I'm treating XML processing as a pipe with a document factory at each stage.

Jon Smirl
jonsm at aol.com



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)