You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-dev@xml.apache.org by Dare Obasanjo <kp...@yahoo.com> on 2002/05/31 18:39:44 UTC
Xindice and SiXDML
This is an update on the efforts provide an
implementation of the Simple XML Data Manipulation
Language (SiXDML) which is an XML:DB initiative
project described at http://www.xmldb.org/sixdml/ for
Apache Xindice.
I will be presenting a paper about SiXDML at the First
VLDB Workshop on Efficiency and Effectiveness of XML
Tools, and Techniques (EEXTT2002)[0] that will be held
in Hong Kong.
Now that I have cleared that hump, I can begin to
guide Sanjay Bhatia's efforts in getting a Xindice
implementation out of the door. My current timetable
is for us to release bimonthly efforts until August
when the conference will be held. The tentative
timetable is
June 14: Updated SiXDML API released to XML:DB
initiative site.
June 28: ANTLR SiXDML parser implementation released
which is compatible with updated API.
July 14: Alpha Xindice implementation released that
utilizes new API and parser.
July 28: Update alpha Xindice implementation based on
feedback.
August 14: More updates to alpha Xindice
implementation based on feedback.
These efforts are intended to fulfill item 4.2 in the
Xindice Planning document[1].
[0] http://www.comp.nus.edu.sg/~ebh/eextt2002/
[1] http://www.xindice.org/papers/planning.html
=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #145
My dungeon cell decor will not feature exposed pipes.
While they add to the gloomy atmosphere, they are good conductors of vibrations and a lot of prisoners know Morse code.
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
Re: Xindice and SiXDML
Posted by "Mark J. Stang" <ma...@earthlink.net>.
All,
I wrote a simplier implementation. I think I the ANTLR based
version. I have a bunch of queries of the form:
select person from customers where lname = 'Stang'
I saw your grammar and thought of using your grammar instead
of mine, mine doesn't use XPath. However, since you are going
to create a Xindice implementation, I think I will wait and see.
If you need help help let me know.
Mark
Stefano Mazzocchi 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.
>
> Dare Obasanjo wrote:
> >
> > This is an update on the efforts provide an
> > implementation of the Simple XML Data Manipulation
> > Language (SiXDML) which is an XML:DB initiative
> > project described at http://www.xmldb.org/sixdml/ for
> > Apache Xindice.
>
> 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.
>
> > I will be presenting a paper about SiXDML at the First
> > VLDB Workshop on Efficiency and Effectiveness of XML
> > Tools, and Techniques (EEXTT2002)[0] that will be held
> > in Hong Kong.
> >
> > Now that I have cleared that hump, I can begin to
> > guide Sanjay Bhatia's efforts in getting a Xindice
> > implementation out of the door. My current timetable
> > is for us to release bimonthly efforts until August
> > when the conference will be held. The tentative
> > timetable is
> >
> > June 14: Updated SiXDML API released to XML:DB
> > initiative site.
> >
> > June 28: ANTLR SiXDML parser implementation released
> > which is compatible with updated API.
> >
> > July 14: Alpha Xindice implementation released that
> > utilizes new API and parser.
> >
> > July 28: Update alpha Xindice implementation based on
> > feedback.
> >
> > August 14: More updates to alpha Xindice
> > implementation based on feedback.
> >
> > These efforts are intended to fulfill item 4.2 in the
> > Xindice Planning document[1].
> >
> > [0] http://www.comp.nus.edu.sg/~ebh/eextt2002/
> > [1] http://www.xindice.org/papers/planning.html
>
> This is really great. I look forward to provide betatesting and realtime
> feedback as soon as we have something to try directly.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
Re: Xindice and SiXDML
Posted by Dare Obasanjo <kp...@yahoo.com>.
--- Stefano Mazzocchi <st...@apache.org> wrote:
>
> 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.
Cool. Please let me know what how the it is received
because I'm always looking for feedback about SiXDML.
> 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.
As someone who's day job requires working intimately
with XQuery and the W3C folks designing it, I can say
that the only distinction that I really see between
XQuery and XSLT is syntactic.
Considering that XSLT 2.0 will use XPath 2.0 which is
_currently_ just XQuery - let & where expressions -
query prolog (schema importation, func definitions,
namespace decls) + reverse & namespace axes - element
construction - sorting ,I think that the distinction
grows more and more hazy.
> 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.
As standards mature, I fully expect for the next
iteration of SiXDML to leverage XPath 2.0, however my
goal was to create a simple, understandable language
and I think adding XQuery to the mix may defeat that
purpose.
However, my research paper does describe how to
augment XQuery to be more SiXDML-like which I'm sure
will be an interesting perspective to some.
> > 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.
Agreed. This is what I'll shoot for in the next
iteration of SiXDML. However, I do have some concerns
about how complex XPath 2.0 is becoming which were
shared by many on XML-DEV[0]
> > 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.
The entire purpose of the having the layered framework
was to get around the lack of transformation/complex
querying in XPath. This may no longer be the case if
XPath 2.0 or as you suggested XQuery is used as the
query language in a SELECT statement.
[0]
http://lists.xml.org/archives/xml-dev/200205/threads.html
=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #79
If my doomsday device happens to come with a reverse switch, as soon as it has been employed it will be melted down and made into limited-edition commemorative coins.
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
Re: Xindice and SiXDML
Posted by Stefano Mazzocchi <st...@apache.org>.
Dare Obasanjo wrote:
>
> --- Stefano Mazzocchi <st...@apache.org> 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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: Xindice and SiXDML
Posted by Dare Obasanjo <kp...@yahoo.com>.
--- Stefano Mazzocchi <st...@apache.org> 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).
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.
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.
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.
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.
=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #145
My dungeon cell decor will not feature exposed pipes.
While they add to the gloomy atmosphere, they are good conductors of vibrations and a lot of prisoners know Morse code.
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
Re: Xindice and SiXDML
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
Dare Obasanjo wrote:
>
> This is an update on the efforts provide an
> implementation of the Simple XML Data Manipulation
> Language (SiXDML) which is an XML:DB initiative
> project described at http://www.xmldb.org/sixdml/ for
> Apache Xindice.
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.
> I will be presenting a paper about SiXDML at the First
> VLDB Workshop on Efficiency and Effectiveness of XML
> Tools, and Techniques (EEXTT2002)[0] that will be held
> in Hong Kong.
>
> Now that I have cleared that hump, I can begin to
> guide Sanjay Bhatia's efforts in getting a Xindice
> implementation out of the door. My current timetable
> is for us to release bimonthly efforts until August
> when the conference will be held. The tentative
> timetable is
>
> June 14: Updated SiXDML API released to XML:DB
> initiative site.
>
> June 28: ANTLR SiXDML parser implementation released
> which is compatible with updated API.
>
> July 14: Alpha Xindice implementation released that
> utilizes new API and parser.
>
> July 28: Update alpha Xindice implementation based on
> feedback.
>
> August 14: More updates to alpha Xindice
> implementation based on feedback.
>
> These efforts are intended to fulfill item 4.2 in the
> Xindice Planning document[1].
>
> [0] http://www.comp.nus.edu.sg/~ebh/eextt2002/
> [1] http://www.xindice.org/papers/planning.html
This is really great. I look forward to provide betatesting and realtime
feedback as soon as we have something to try directly.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------