XQuery and Item Orientation

[Ghislain Fourny]

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: http://x-query.com/mailman/listinfo/talk
[mailto:http://x-query.com/mailman/listinfo/talk] On Behalf Of Hans-Juergen Rennau
Sent: 20 January 2009 07:47
To: http://x-query.com/mailman/listinfo/talk
Subject:  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

_______________________________________________
http://x-query.com/mailman/listinfo/talk
http://x-query.com/mailman/listinfo/talk

_______________________________________________
http://x-query.com/mailman/listinfo/talk
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