|
»
XSLT extension?
|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
 |
XSLT extension?
by Andrzej Jan Taramina
::
Rate this Message:
Just curious as to what the rationale is for building a custom xslt extension is?
Seems like a lot of work to duplicate the work done by Apache (Xalan) or the industry benchmark, Saxon.... -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Exist-open mailing list Exist-open@... https://lists.sourceforge.net/lists/listinfo/exist-open |
|
|
Re: XSLT extension?
by Wolfgang Meier-2
::
Rate this Message:
> Just curious as to what the rationale is for building a custom xslt
> extension is? > > Seems like a lot of work to duplicate the work done by Apache (Xalan) > or the industry benchmark, Saxon.... You could as well ask why eXist needs its own XQuery engine. Xalan and Saxon are in-memory processors which do not benefit from eXist's persistent DOM or its index structures. They use a completely different design. eXist's current XSLT support thus needs to serialize a document into memory before passing it to Saxon or Xalan. This is very inefficient. For efficient queries, you always have to use eXist's own XQuery engine. Dmitriy's XSLT extension could change this. It is really just an additional frontend to eXist's query engine, using the same index-assisted XPath2 core. Wolfgang ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Exist-open mailing list Exist-open@... https://lists.sourceforge.net/lists/listinfo/exist-open |
|
|
Re: XSLT extension?
by Andrzej Jan Taramina
::
Rate this Message:
Wolfgang:
> You could as well ask why eXist needs its own XQuery engine. Xalan and > Saxon are in-memory processors which do not benefit from eXist's > persistent DOM or its index structures. They use a completely different > design. Makes sense for XQuery, though I'm not sure it's as big a deal for XSLT, given the work that will be required. > eXist's current XSLT support thus needs to serialize a document into > memory before passing it to Saxon or Xalan. This is very inefficient. > For efficient queries, you always have to use eXist's own XQuery engine. Or get Michael Kay to help integrate Saxon more closely so that it can use eXist's internal persistent DOM. ;-) > Dmitriy's XSLT extension could change this. It is really just an > additional frontend to eXist's query engine, using the same > index-assisted XPath2 core. Will it support XSLT 2.0? -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Exist-open mailing list Exist-open@... https://lists.sourceforge.net/lists/listinfo/exist-open |
|
|
Re: XSLT extension?
by Wolfgang Meier-2
::
Rate this Message:
> Makes sense for XQuery, though I'm not sure it's as big a deal for
> XSLT, given the work that will be required. It depends on how you are using XSLT. If you just need it to transform a small XML fragment returned by an XQuery, ok, that's not a big deal. But it really gets difficult if you need access to other parts of the db from within the XSLT. Right now, the only possibility is to call an XQuery via REST and integrate its results into XSLT. > Or get Michael Kay to help integrate Saxon more closely so that it > can use eXist's internal persistent DOM. ;-) The effects would not be as expected. The differences between both approaches are just too big: Saxon is optimized towards streaming and fast tree traversals based on iterators, while eXist tries to avoid those wherever possible (because IO costs are high and loading the actual nodes from disk is slow). What makes eXist efficient is the combination of a persistent DOM with a node numbering scheme, join algorithms and indexes. You need all those components, not just one. This necessarily leads to a completely different design (not better or worse, just different). > Will it support XSLT 2.0? Sure, if it is built on the same foundation as the XQuery engine, it has to be XSLT2.0. Wolfgang ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Exist-open mailing list Exist-open@... https://lists.sourceforge.net/lists/listinfo/exist-open |
|
|
Re: XSLT extension?
by Andrzej Jan Taramina
::
Rate this Message:
Wolfgang:
> It depends on how you are using XSLT. If you just need it to transform a > small XML fragment returned by an XQuery, ok, that's not a big deal. But > it really gets difficult if you need access to other parts of the db > from within the XSLT. Right now, the only possibility is to call an > XQuery via REST and integrate its results into XSLT. Makes sense.... > The effects would not be as expected. The differences between both > approaches are just too big: Saxon is optimized towards streaming and > fast tree traversals based on iterators, while eXist tries to avoid > those wherever possible (because IO costs are high and loading the > actual nodes from disk is slow). What makes eXist efficient is the > combination of a persistent DOM with a node numbering scheme, join > algorithms and indexes. You need all those components, not just one. > This necessarily leads to a completely different design (not better or > worse, just different). Good insight there.... >> Will it support XSLT 2.0? > > Sure, if it is built on the same foundation as the XQuery engine, it has > to be XSLT2.0. Not necessarily. The new XSLT compiler would have to support some of the new XSLT elements/operations as well to be 2.0 compliant. XPath 2.0 is just one component of that. Thanks for the info....it'll be interesting to see if some of my really complex rendering XSLTs will benefit from the new extension when it's ready. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Exist-open mailing list Exist-open@... https://lists.sourceforge.net/lists/listinfo/exist-open |
|
|
Re: XSLT extension?
by Florent Georges-3
::
Rate this Message:
Andrzej Jan Taramina wrote:
Hi, > > You could as well ask why eXist needs its own XQuery engine. > > Xalan and Saxon are in-memory processors which do not benefit > > from eXist's persistent DOM or its index structures. They > > use a completely different design. > Makes sense for XQuery, though I'm not sure it's as big a deal > for XSLT, given the work that will be required. Oh yes, that would be interesting to have native XSLT support. And I've never understood why native XML databases have not taken the same path as Saxon: implementing XDM and F&O, then providing both XSLT and XQuery front-ends... A priori, if you have XQuery, that wouldn't be that difficult to have XSLT. That's a very good news IMHO. Regards, -- Florent Georges http://www.fgeorges.org/ ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Exist-open mailing list Exist-open@... https://lists.sourceforge.net/lists/listinfo/exist-open |
| Free embeddable forum powered by Nabble | Forum Help |
