Re: re re problem with xalan1 and namespaces@8@1

[Sebastien Sahuc <ss...@imediation.com>]

Giacomo Pati wrote :
> --- Sebastien Sahuc <ss...@imediation.com> wrote:
> > Giacomo wrote :
> > > I've done some testings too and found that DOM support is somehow
> > > lacking in Xalan2 and this is extremely needed in the XSP engine.
> > SAX
> > > support seems to be ok for Transformers so far.
> >
> > So it won't be a problem to use Xalan 2 inside XSP. Indeed you just
> > need
> > to produce SAX events from a Dom tree when feeding the source to the
> > XSL
> > processor, and then build the result DOM  tree from generated SAX
> > events.
> > Does it make sense ?

> Wouldn't that be overkill?

Well i don't know Xalan2 well enough but what I've learned from XT might 
be true for Xalan2 :

XT uses a internal-lightweight tree representation of the source document 
(a very light DOM optimized for the purpose of XSLT), therefore I found 
out that it was way faster to generate SAX events from a DOM source than 
submitting the DOM source tree to the XSL processor. The same is true for 
the output result, because in any case the DOM tree is built from result 
SAX events, so it doesn't matter when this step is done.

Keep in mind that when you create a DOMParser form the DOM source tree, 
then the XSL processor is not parsing the input tree but rather building 
it's internal-optimized Node tree from these SAX events. 
And when the DOM source tree is submitted directly to the XSL processor, 
I believe that the internal-optimized node tree is built by wrapping the 
DOM tree, which is overkill IMHO ! 

Did I make myself clear ? If not, I'll be glad to elaborate more on this 
point since I believe it to be important enough.


> > By the way, why don't we get rid of these DOM tree in XSP ? Indeed
> > it's
> > just a matter of transforming XML source though couple of
> > transformers
> > don't you think ?

> Because of the way XSP works. In the input XML document you may have
> processing-instruction telling the XSP engine which logicsheet to apply
> next. The resulting document may have other processing-instructions
> generated from the former logicsheet (logicsheets depending on other
> logicsheets). Thus the resulting documents has to be instected by the
> XSP engine to evaluate and apply them, and so forth. And this is IMHO
> best done with DOM.


Well this is why transformers have been created for, no ? 

Below is the way it could work with transformer :

When the SAX events for the original XSP document is submitted to the XSP 
transformer, then when the 'processing intruction SAX event' is thrown, 
the method 'processingInstruction(target, data)' acts as a controller and 
set a new transformer on the fly that correspond to the stylesheet 
declared in the PI. Therefore all the following SAX events are forwarded 
to the new transformer we've just set up. 
Then this later transformer send its result SAX events to the XSP 
transformer which acts one more time as a controller. And we repeat the 
loop until there is no more PI to handle. 

Does it make sense ?

All the best,


Sebastien

> Giacomo

> =====
> --
> PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
> Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
> Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
> CH-8166 Niederweningen                    Web:   http://www.pwr.ch

> __________________________________________________
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo! Messenger.
> http://im.yahoo.com/