Re: [xsl] object-oriented XSL

[martin@xxxxxxxx]

On Sun, 25 Aug 2002, Jeni Tennison wrote:
>
> You'll be able to do this in XSLT 2.0. The functions have to be in a
> namespace, and the result of the function is indicated through a
> xsl:result function; you're only allowed parameter and variable
> definitions before the xsl:result element, so the above will look
> something like:
>
> <xsl:function name="my:fib">
>   <!-- calculates fibonacci numbers recursively -->
>   <xsl:param name="n" />
>   <xsl:result select="if ($n &lt;= 2)
>                       then 1
>                       else my:fib($n - 1) + my:fib($n - 2)" />
> </xsl:function>

excellent! where can i read more about XSLT2.0?
though does no-one else feel that putting program constructs
(if/then/else) in the expression language is duplicating things a bit?

the namespace is a great way of modularising functinality - my 'full'
example would have been (algorithm hopefully fixed! :)

  <o:function name="my:fib">
    <o:param name="n"/>
    <o:do>
        <o:choose>
          <o:when test="$n &lt;= 1"><o:return select="1"/></o:when>
          <o:otherwise><o:return select="my:fib($n - 1) + my:fib($n - 2)"/></o:otherwise>
        </o:choose>
    </o:do>
  </o:function>

(note the 'do' and 'return' statements)

> The path that XSLT 2.0 and XPath 2.0 is going down is that you define
> "types" using W3C XML Schema. Types in W3C XML Schema are obviously
> different from types in normal programming languages, since they're
> oriented around XML structures, but a User type might look something
> like:
>
> <xs:complexType name="User">
>   <xs:attribute name="name" type="xs:token" />
> </xs:complexType>

perfect for data description, but doesn't achieve object encapsulation.
there's no separation of public/private i/f and the data is static.
now if the object had a state, and functions...

> I think that it would be great if instead we could do things like:
>
>   $dur.years()
>   $name.local-name()
>
> to get hold of the property (though there are some syntax problems
> with that, since '.' is a name character in XML/XPath/XSLT.)

it's a conflict with a workaround, as you can always use [name() = 'xy.z'].
the real limitation i think lies in that the XSLT model won't allow for
the object to change its data (state), so you're limited to simple getter
functions.
or... well i guess you could do pretty advanced logic without changing the
state, and just return new objects as needed. functional oo programming??
now i've got food for thought!

btw does XSLT 2.0 describe higher-order functions as well?

cheers,

/m


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list