[xquery-talk] XQuery and Item Orientation

[Michael Kay]

What you're proposing isn't that far removed from XSLT's pattern matching
capability. And of course as any XSLT user knows, this kind of polymorphic
despatch mechanism is extremely valuable in dealing with data whose
structure is variable. Of course XSLT's patterns are more flexible than what
you are proposing, because they match against arbitrary predicates, not only
against the type hierarchy - again, that's needed because of the variety of
ways in which people express structural relationships in XML.

The XQuery designers have been very opposed to any kind of dynamic despatch
or polymorphism, because it makes many kinds of static optimization
impossible. In this sense, the language is optimized for the large database
environment where user convenience has to be sacrificed to the needs of
performance.

Michael Kay
http://www.saxonica.com/


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