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

[Hans-Juergen Rennau]

Thank you
for pointing to this technique of emulating polymorphic functions in XSLT – very
nice. And the direction XSLT is heading seems very promising to
me.
 
I
emphatically agree with your statement that not type hierarchy but patterns (or
general XPath expressions – test expressions) should be the basis of
polymorphism. As the discussions have helped to further clarify my thoughts, I
would like to propose a new summing up of “item orientation”.
 
a) Starting
point:  object orientation is more than a
mechanism of dispatch – rather a way of thought, influencing the way we model
systems, because it influences the conceptual units we combine into systems. The
introduction of object orientation means to gain a new modeling perspective.
 
b) Item
orientation can be viewed as *projection* of object orientation to the plane
of  XML data. Projection in the sense of:
keep what you can, and discard what you cannot. The main loss comes by mapping
a function in the broad sense of programming languages to an XQuery function
with its intrinsic limitation of “no side effects!”. This is a loss, and still
the mapping makes sense:
 
object 
=> item
 
member
function 
=> item
function, that is, function with implicit access to the item’s data
 
member
function’s polymorphism based on type hierarchy and type-interface relationships 

=>  item function’s polymorphism based
on competing match conditions
 
object
interface 
=> all
functions that can be bound to the given item
 
class
interface 
=> a set
of functions which happen to have the same match conditions
 
When it
comes to the class interface, the mapping is deliberately lightweight in order
to preserve the phantastic agility and interoperability which the uniform data
model (six kinds of nodes, three kinds of node relationship) offers; arguably, a
need to explicitly define “interfaces” or “classes” might comprise them.
 
With kind
regards –
Hans-Jüergen
Rennau



----- Ursprüngliche Mail ----
Von: Michael Kay <mike at saxonica.com>
An: Hans-Juergen Rennau <hrennau at yahoo.de>
CC: talk at x-query.com
Gesendet: Donnerstag, den 22. Januar 2009, 01:24:40 Uhr
Betreff: RE: [AW] XQuery and Item Orientation

> 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/