[
Lists Home |
Date Index |
Thread Index
]
Hi!
Here a few comments:
> -----Original Message-----
> From: Dare Obasanjo [mailto:kpako@yahoo.com]
> Sent: Wednesday, January 09, 2002 01:17
> To: xml-dev@lists.xml.org; Jonathan Robie
> Subject: Re: [xml-dev] XQuery Update Proposal
>
>
> ----- Original Message -----
> From: "Jonathan Robie" <jonathan.robie@softwareag.com>
> To: <xml-dev@lists.xml.org>
> Sent: Thursday, January 03, 2002 8:45 AM
> Subject: [xml-dev] XQuery Update Proposal
>
> > Several people asked for me to post the update proposal I
> presented at
> > XML 2001. Patrick Lehti has now posted his thesis, which
> contains this
> > proposal, to the web:
> >
> > http://www.lehti.de/beruf/diplomarbeit.pdf
> >
> > I expect this proposal to change somewhat.
>
> Here're some of my thoughts 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]
>
I think you are right with the namespace awareness.
> 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 .
>
"INSERT PRECEDING" and "INSERT FOLLOWING" were used, because "before"
and "after" were already used in the XQuery grammar, which would result
in an ambiguous grammar. In the latest XQuery working draft (December
01) this was changed, so now it is possible to use "INSERT BEFORE" and
"INSERT AFTER" again.
> 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].
>
Yes, both expressions would be fine. It simply shows nested conditional
updates.
> Page 28:
> FLW-Updates look very useful.
>
>
> [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 #71
> If I decide to test a lieutenant's loyalty and see if he/she
> should be made a trusted lieutenant, I will have a crack
> squad of marksmen standing by in case the answer is no.
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org
> <http://www.xml.org>, an initiative of OASIS
<http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
