[xquery-talk] RE: [AW] XQuery and Item Orientation

[Markus Pilman]

> I agree that XQuery desperately needs some kind of polymorphism, but I'm not
> convinced that the traditional type hierarchy of object-oriented systems
> maps well to the XML world as the basis for despatching.
But when I look at the proposed solution by Unity, I have the
following impressions:

1. I like the idea of human readable schema very much! Although XQuery
was designed to handle unstructured data (and it is good at it), most
of my data I handle with XQuery is structured or, at least,
semi-structured. But writing XML Schema is pain and importing and
using it in XQuery is not intuitive at all. With the use of classes,
this problems would go away.
2.) The possibility, that a function takes implicitly the context as
the first argument is, as said before, "just" syntactic sugar. But for
me, this would be a big step forward: I really like sugar :-)

With these to features, there are only two of the big main concepts of
object orientation missing (did not think too long about it - so it's
possible that I miss something): information hiding and dynamic
binding. I think information hiding would be a problem, but what is
wrong about defining a "virtual" keyword for functions? Of course,
this will affect performance, but this is an acceptable price,
regarding the benefits we would get with such a feature.

I think it is a question, about which use cases we talk: on a database
I do not need these features. But in application programming, this
would make a lot of sense. Writing a web application in Unity seems to
me to be more comfortable than in XQuery.

On Thu, Jan 22, 2009 at 10:24 AM, Michael Kay <mike at saxonica.com> wrote:
>> XSLT's polymorphism does not breathe object-orientation. It
>> is meant for, as you put it, "dealing with data whose
>> structure is variable", it is less appropriate for creating
>> interfaces whose abstraction hides the variability of
>> concrete behaviour. I perceive templates in the first place
>> as a mechanism for uniform triggering of variable processing
>> - trigger it and get it done. Just compare the ease of using
>> a function call within an expression with the cumbersome
>> voodoo required for catching a template's output and make it
>> input for further processing!
>
> I agree with all that: but you can use XSLT's templates to achieve this kind
> of thing if you choose to.
>
> For example
>
> <xsl:function name="geo:area" as="xs:double">
>  <xsl:param name="shape" as="schema-element(polygon)"/>
>  <xsl:apply-templates select="$shape" mode="get-area"/>
> </xsl:function>
>
> <xsl:template match="rectangle" mode="get-area" as="xs:double">
>  <xsl:sequence select="@width*@height"/>
> </xsl:template>
>
> <xsl:template match="circle" mode="get-area" as="xs:double">
>  <xsl:sequence select="@radius*@radius*$PI"/>
> </xsl:template>
>
> etc. Providing a function as an interface to a set of templates in this way
> eliminates all the voodoo as far as the caller is concerned. In XSLT 2.1
> we're hoping to get some more modularity/encapsulation into this so you can
> declare, for example, that the mode is private to a module and the function
> is public.
>
>> I am just trying to say that polymorphic functions would
>> introduce something into X-technology that XSLT's templates
>> do not well cover:
>
> I agree that XQuery desperately needs some kind of polymorphism, but I'm not
> convinced that the traditional type hierarchy of object-oriented systems
> maps well to the XML world as the basis for despatching. Patterns with
> user-defined priority give more flexibility.
>
> Michael Kay
> http://www.saxonica.com/
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk
>