XQuery and Item Orientation

[Brian Maso]

I'm a language slut as much as anyone, but I feel like this territory has
been covered. I think initially of Cu (.Net platform), a language that has
XML, relational, and OO structures all as first-class citizens.

I like that XQuery has tight focus -- I think of it as a functional DSL for
processing XML, and that's a great thing. (Adding functions as first-class
types would really kick ass, though!) But adding "methods" to XSD types? Eh
(shrug).

Brian Maso

On Tue, Jan 20, 2009 at 3:38 PM, Ghislain Fourny <http://x-query.com/mailman/listinfo/talk>wrote:

> 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/
>
>
>
> _______________________________________________
> 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/36e9db47/attachment.htm