Trax, DTM, lazy DOM

[David Ireland <da...@lshift.net>]

I am supplying a transform with a DOM source. The DOM in the source is constructed lazily by traversing objects in a database.

I know Xalan has a version of the DTM which accesses a DOM, so it seems like the transform could lazily traverse the database. Sadly, this isn't whats happenning - the DOM gets serialized, and rebuilt into another DTM. This is extemely innefficient.

It doesn't seem like it would be that hard to get around this. I'd like still to be able to use TRAX, but can't find where to invoke the transformer with a DTM either.

Cheers
David


-- 
  [][][] David Ireland  | Mob: +44 (0)79 7076 3599
    [][] LShift Ltd     | Tel: +44 (0)20 7729 7060
  []  [] www.lshift.net | Email: david@lshift.net

Re: Trax, DTM, lazy DOM

[John Gentilin <ge...@eyecatching.com>]

Since the DTM is an internal implementation to help DOM navigation, its not
available as a Type of Data source available to the Transformation. You could
pass your interface as Parameter that is utilized as an extension. That way
you could provide the interface as a DTM and control how the document is put
together. If you look at the SQL extensions that are provided as part of Xalan
you will see an example of something similar to what you are trying to accomplish.
The SQL Extensions support both a lazily built document and streaming mode where 
the only portion of the document that exists in memory is the current row. i.e.
A sliding window of the DB.

John G

David Ireland wrote:
> David Ireland wrote:
> 
>>
> 
>> I know Xalan has a version of the DTM which accesses a DOM, so it 
>> seems like the transform could lazily traverse the database. Sadly, 
>> this isn't whats happenning - the DOM gets serialized, and rebuilt 
>> into another DTM. This is extemely innefficient.
>>
> 
> OK, some investigation of the Xalan source, and some stack traces later, 
> I know that DOM2DTM is being used, and that its the transformer that is 
> being greedy. My test transformation is carefully written not to be 
> greedy, and it gives the expected output, if I arrange for my DOM to be 
> pruned.
> 
> Is there a way around this?
> 
> Cheers
> David
> 

Re: Trax, DTM, lazy DOM

[David Ireland <da...@lshift.net>]

David Ireland wrote:
> 

> I know Xalan has a version of the DTM which accesses a DOM, so it seems 
> like the transform could lazily traverse the database. Sadly, this isn't 
> whats happenning - the DOM gets serialized, and rebuilt into another 
> DTM. This is extemely innefficient.
> 

OK, some investigation of the Xalan source, and some stack traces later, I know that DOM2DTM is being used, and that its the transformer that is being greedy. My test transformation is carefully written not to be greedy, and it gives the expected output, if I arrange for my DOM to be pruned.

Is there a way around this?

Cheers
David

-- 
  [][][] David Ireland  | Mob: +44 (0)79 7076 3599
    [][] LShift Ltd     | Tel: +44 (0)20 7729 7060
  []  [] www.lshift.net | Email: david@lshift.net

Re: Trax, DTM, lazy DOM

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

If you're using XSTLC, then yes, I believe we do currently serialize and
deserialize the DOM. That's old pre-DTM XSLTC code which hasn't yet been
rewritten.

If you're using interpretive Xalan, we should be building DOM2DTM lazily --
but how lazy we can be depends on how much of the document your stylesheet
accesses, and the lazy build is linear (depth-first preorder) due to some
of the assumptions built into the DTM APIs. We have an experimental
DOM2DTM2 which attempts to build nonlinearly, but it operates under some
fairly severe limitations on which DOMs it can support and it has its own
efficiency traceoffs. This is why we've spent some time investigating the
XDM concept, which is easier to wrap around a wider variety of back-end
data models.

______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk