XQuery and Item Orientation

[Ghislain Fourny]

Hello,

I totally agree with you that this is a rather minor step forward, but  
as a programmer, I really value the possibility to have a way to  
structure a program in modules and classes if the data is highly  
structured: it makes the code easier to understand and it makes it  
easier to build big applications. This is one step towards  
encapsulation, without removing the ability of XQuery to deal with  
unstructured data. But this might be simply a matter of taste and of  
programming style, so this is somehow subjective.

Regarding static typing and Saxon: we do not use Saxon for the static  
typing which determines which method is executed. Instead, we perform  
a very basic and well-defined static typing on complex types based on  
explicit type declarations and on the imported schema. Saxon SA is  
only used to execute the compiled output, in which the method has  
already been bound. So if you make changes to your optimisations, this  
will not affect the result of the queries.

Kind regards,
Ghislain Fourny

>
> 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.
>
> I don't think static polymorphism (overloading based on the static  
> type of the arguments - here the implicit first argument) - is a  
> particularly useful step forwards. It gives a minor syntactic  
> convenience for the kind of highly structured data where static  
> typing works, but the real need is for something more dynamic.
> I'm all in favour of allowing a function to declare that it takes  
> the context item as an implicit parameter, but that's just a bit of  
> syntactic sugar.
> 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.
>
> I think that if you are despatching different methods based on the  
> results of static type inferencing, then the static type rules need  
> to be visible to, and comprehensible to, the users of the language.  
> That isn't the case with Saxon's current static typing, which is  
> designed for optimization and diagnostics only - it shouldn't affect  
> the result of the query, so it's done as intelligently as Saxon  
> considers appropriate. I would be very concerned about "freezing"  
> the static typing rules in such a way that a change to make it more  
> clever could affect the results of user queries.
>
> Michael Kay
> http://www.saxonica.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://x-query.com/pipermail/talk/attachments/20090121/f4a9af25/attachment.htm