Re: XQuery, UPDATES and XML repositories

----- Original Message -----
From: "Jonathan Robie" <jonathan.robie@softwareag.com>
To: "Dare Obasanjo" <kpako@yahoo.com>; "XQuery WG"
<www-xml-query-comments@w3.org>
Sent: Friday, January 11, 2002 12:54 PM
Subject: Re: XQuery, UPDATES and XML repositories


> At 02:30 PM 12/27/2001 -0800, Dare Obasanjo wrote:
> >In certain discussions on the xml-dev mailing list it came to my attention
> >that the W3C is considering letting XQuery go to recommendation status
without
> >UPDATE or DELETE semantics being a part of the recommendation. Below are
> >various comments I've made regarding the lack of a data manipulation
language
> >for XML  and how it adversely affects XMl repositories like native XML
> >databases and XML-enabled databases.
> >
> >1.)  What has struck me particularly as being unfortunate is that I've yet
to
> >see an XML data
> >manipulation language with the simple SELECT-UPDATE-DELETE semantics that
> >users of relational databases (i.e SQL users) and hierarchical databases
(i.e.
> >DL/I users) have had for years and have come to take for granted.
>
> Hi Dare,
>
> You are probably aware that both Software AG and Microsoft have implemented
> updates as an extension to XQuery. The following thesis describes the
> Software AG implementation of updates:
>
> http://www.lehti.de/beruf/diplomarbeit.pdf

I gave my thoughts on this proposal on the XML-DEV list but here they are
again for the XQuery WG:

These comments are based on the parts of the paper I read, pages 23
thru 31 on .update extensions to XQuery.

Page 23:
I mostly agree with the choices of "musts", "shoulds" and "mays" but would
promote namespace awareness to a "must" instead of a "should" specifically
with regards to inserting attributes. I'd hate for the ability to insert
attributes from different namespaces to vary between different compliant
XQuery implementations. Speaking of which there doesn't seem to be a way to
construct an attribute with a given namespace prefix and namespace URI in the
current version of the XQuery spec [0]

Page 25:
I prefer the clauses "INSERT BEFORE" and "INSERT AFTER" to "INSERT PRECEDING"
and "INSERT FOLLOWING" because the former are clearer for most to understand
and are already used by XUpdate .

Page 27:
Is there any reason the conditional update expression written as

    UPDATE
    IF (count(//employee)>1000) THEN

    IF (count(//employee[sex=male]>100)) THEN

    DELETE //employee[sex=male]

couldn't have been written as

    UPDATE
    IF ((count(//employee)>1000) AND (count(//employee[sex=male]>100))) THEN

    DELETE //employee[sex=male]

Anyway I think prefer the above construct to MSFT's UPSERT clause [1].

Page 28:
FLW-Updates look very useful.


> You can download Software AG's implementation here:
>
> http://www.softwareag.com/developer/quip/default.htm
>
> I am not aware whether there is documentation for the Microsoft
> implementation (perhaps Michael Rys can say?), but there is a grammar and
> some running examples, which you can find here:
>
> http://xmlqueryservices.com/
>
> Both the Microsoft and Software AG implementations go back to an earlier
> proposal created jointly with IBM and CrossGain. The companies who worked
> on this proposal, and those that have implemented updates, obviously agree
> with you that updates are important. However, it is vital that updates be
> based on a well-defined language, and getting the current set of operators
> in XQuery to be completely defined is clearly the first step.
>
> I think you will continue to see pressure on the XML Query WG to do
> updates. If you had to choose between an XQuery spec without updates, and
> one with updates perhaps 6 months later, which would you prefer? What if
> the update proposal were a separate proposal that came out 6 later, would
> that be acceptable to you?

I am interested in XQuery from a database perspective and the problem I see
with releasing XQuery without updates is that almost all of the vendors of
native XML databases & XML-enabled databases that are interested in XQuery
seem to also be involved in implementing updates as extensions to XQuery. It
would be unfortunate if XQuery became like SQL where people follow the spirit
but not the letter of the standard and almost no two relational databases
share the same syntax and semantics for SQL. An XQuery recommendation without
updates may lead to a few months or even a year of XQuery + proprietary
extensions gaining a foothold in certain markets, and may lead to a similar
balkanization of XQuery. My preferences of a release time frame for an XQuery
recommendation in order of importance is

****  XQuery recommendation with updates, regardless of if this makes XQuery
ship a little later.
***    XQuery recommendation without updates which is obsoleted by a version
with updates shortly afterwards.
**      XQuery recommendation without updates and a seperate proposal 6 months
later.
*        XQuery recommendation without updates.


[0] http://www.w3.org/TR/xquery/#computedConstructors

[1] http://131.107.228.20/demoright.aspx?case=DML&example=5


--
THINGS TO DO IF I BECOME AN EVIL OVERLORD #1
My Legions of Terror will have helmets with clear plexiglass visors, not
face-concealing ones.



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Received on Monday, 14 January 2002 21:25:55 UTC