Dare Obasanjo wrote:
>
> --- Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> > Dare,
> >
> > thanks much for your effort on SiXDML. I've
> > submitted it for review to
> > the JSR 170 (Java Repository API) where I'm the
> > official Apache
> > representative. We'll see what happens.
>
> The XML:DB initiative site is down now but I'd like to
> find out what you submitted. The API and the language
> although once tied together are now seperate. Also, I
> shall be creating another version of the API
> (basically a level 1A & level 1B conformance level
> that are orthogonal to each other).
I sent a pointer to the SiXDML language since they were talking about an
SQL-like query language and thought they might not be aware of it.
We are not dealing with the API level yet.
> Level 1B will be the current API while Level 1A will
> be an API similar to ODBC & JDBC that is geared
> towards executing commands passed as strings or
> parameters.
>
> >
> > I have a question for you: what does it mean to run
> > a 'select' query
> > thru an XQuery transformation stage?
> >
> > I understand perfectly the XSLT case (which might be
> > interesting for
> > server-side optimizations, even if I think that
> > transformations normally
> > happen at another level).
> >
> > The XPath and XQuery samples used as a transforming
> > post-process are
> > puzzling me. Can you give me your thoughts on this.
>
> Currently XPath 1.0 is not sophisticated enough for
> complex queries and it doesn't perform
> transformations. Both XSLT and XQuery in its current
> can be used for complex queries and transformation.
I dare to disagree. XSLT was designed to be a transformer of SAX events
(events flow in, they get changed depending on the stylesheet
information, events flow out). XQuery was designed to be a generator of
SAX events (the query comes in, the events flow out).
Sure, XSLT can be made to act as a generator and XQuery can be made to
act as a transformer, but both appear hacks to me and go right against
the need for two different things, one for transformation and one for
generation.
I think the 'select' statement should have the ability to use XQuery
right inside the 'select' statement, not as a post-process facility,
which is the place for XSLT.
XPath, can be used as a simplified version of XQuery inside the select
statement.
> However with the advent of XPath 2.0 which currently
> looks like it will be a large subset of XQuery then
> the need to create such layering of query engines will
> be unnecessary.
Yes XPath 2.0 will simplify layering of all those things.
> Piping query results to XSLT and other query engines
> may be expensive performance wise since the way I
> originally conceived it involves obtaining all the
> results from the XPath query then passing those to the
> XSLT or other engine and in fact that's how it is
> currently implemented in the reference implementation.
Yes, this is my concern entirely and also shows some architectural
problems that IMO originate from the very design of the SiXDML language.
> Efficient implementations would have to either stream
> the XPath results to the other query engine or
> integegrate both engines tightly to boost performance.
>
> Another issue may be crop up if future versions of
> XQuery support updates. I currently am unsure of how
> to solve this problem but since it is currently
> theoretical, I haven't given it much thought.
It seems that XQuery won't have update until next year, so we have
plenty of time :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
