XQuery and Item OrientationGhislain Fourny gfourny at inf.ethz.ch
Wed Jan 21 00:38:08 PST 2009
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format