[xquery-talk] XQuery and Item Orientation
Ghislain Fourny
gfourny at inf.ethz.ch
Tue Jan 20 11:33:25 PST 2009
Hello,
First, as an XQuery user (but this is only my opinion), object
orientation (or as you call it item-orientation) is a feature which I
would appreciate to have in XQuery.
Here are a couple of words regarding implementation.
In my research group, we are actually working on a project about
object orientation in XQuery, called Unity. We did not go into dynamic
binding or polymorphism, but basically, we simply tried to introduce
code in the schema to allow constructs like, following your idea:
$triangle/rotate()
where the context item is passed as a hidden parameter to the method
rotate. The method rotate is defined in the schema for the static type
of $triangle.
To put code in the schema, we added "classes" to the XQuery syntax. A
class is simply a complex type definition written in (a text-version
of) XML Schema, containing, in addition to elements and attributes,
also methods. In these methods, unlike in (most) XQuery functions, the
context item is defined. Of course, an alternative way would be to
really use XML Schema in its original XML format and define methods
separately in an XQuery file.
For example, a complex type containing code could be defined with code
like:
declare class HanoiProblem {
element numOfTowers as xs:positiveInteger occurs 1-1; (: we did
not reinvent the wheel, this is just a text version of XML Schema
(here, implicitely a sequence) :)
element src as xs:string occurs 1-1;
element aux as xs:string occurs 1-1;
element dst as xs:string occurs 1-1;
method solution() {
solve(getTowers(), src, aux, dst)
}
method solve($n as xs:integer, $src as xs:string, $aux as
xs:string, $dst as xs:string) {
if ($n eq 0)
then ()
else (
solve($n -1, $src, $dst, $aux),
move($src, $dst),
solve($n -1, $aux, $src, $dst)
)
}
method move($src as xs:string,$dest as xs:string) {
<move>
<source>{$src}</source>
<destination>{$dest}</destination>
</move>
}
method getTowers() as xs:integer{
numOfTowers
}
};
And it could be used with code like:
let $hanoiProblemInstance as element(my:HanoiProblem) :=
fn:doc("hanoi.xml")/my:hanoi
let $n := $hanoiProblemInstance/my:getTowers()
let $solution := <solution forN = "{$n}">{$hanoiProblemInstance/
my:solution()}</solution>
return $solution
We have implemented a cross-compiler which compiles Unity code to
XQuery+XML Schema, and could test the output successfully with Saxon
SA on several examples. We did not encounter any major issues during
the implementation. One issue could be a name collision between a
method and a function, which can be solved by looking at methods for
the static type of the context item first, and then at functions.
We are now thinking of adding this functionality to an existing schema-
aware XQuery engine to see how it performs.
Of course I would also be happy to hear comments on object-orientation
in XQuery. Perhaps other research groups are also working on this topic?
Kind regards,
Ghislain Fourny
-----Original Message-----
From: talk... at x-query.com
[mailto:talk... at x-query.com] On Behalf Of Hans-Juergen Rennau
Sent: 20 January 2009 07:47
To: ta... at x-query.com
Subject: [xquery-talk] XQuery and Item Orientation
Hello People,
I would like to learn about your thoughts about a perspective
of introducing "item orientation" - an echo of object
orientation - into XQuery.
Starting point: in my opinion, software development has
undergone two revolutions: object orientation, and
XML/XPath/XQuery, both acting as reducers of complexity.
Suddenly it appears strange to me that XQuery makes no
attempt to incorporate object oriented features. More
concretely, I think of binding functionality to a) type and
b) instance. Imagine a second kind of function were
introduced into the language, call it itemFunction, which is
invoked like an object's member function, where the "object"
is an item:
$triangle->rotate()
or
$triangles/.->rotate()
Within the function body, the item is available as the
context item expression (its top level uses, of course). So
much for the binding to an instance. Now the binding to a
type. This amounts to some sort of test used to select the
appropriate function definition for a given item. An obvious
possibility were to bind function declarations to an item
type which must be matched by the item on which the function
is invoked, for example thus:
declare itemFunction element(tringle) local:rotate() {...}
declare itemFunction element(square, squareType)
local:rotate() {...}
More flexibility is gained by the additional possibility to
specify an item test in the form of an XPath expression:
declare itemFunction element(), itemTest="@geometrical eq true()"
element(tringle, triangleType) local:rotate() {...}
To demonstrate the simplicity to be gained, imagine the task
to edit a sequence of reports for rendering purposes. You might write
$reports/.->render()
and start with a default implementation of the itemFunction
'render'. Later, you refine the rendering by simply *adding*
special versions, and you can even do so by just importing
additional modules.
My questions to you:
- would such extensions of XQuery be desirable (from the
user's point of view)
- would such extensions introduce drawbacks or problems (from
the implementor's point of view)
Thank you for any comments!
Hans-Juergen Rennau
_______________________________________________
ta... at x-query.com
http://x-query.com/mailman/listinfo/talk
_______________________________________________
ta... at x-query.com
http://x-query.com/mailman/listinfo/talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://x-query.com/pipermail/talk/attachments/20090120/e1f841fb/attachment.htm
More information about the talk
mailing list