[xquery-talk] XQuery and Item Orientation
gfourny at inf.ethz.ch
Wed Jan 21 00:38:08 PST 2009
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.
> 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:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk