This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: object-oriented XSL


Hi Martin,

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

You can find the XSLT 2.0 WD at:

  http://www.w3.org/TR/xslt20

You can find the various specs related to XPath 2.0 at:

  http://www.w3.org/TR/query-datamodel
  http://www.w3.org/TR/xpath20
  http://www.w3.org/TR/xquery-operators

> though does no-one else feel that putting program constructs
> (if/then/else) in the expression language is duplicating things a
> bit?

Yes. A lot of us feel that XPath 2.0 duplicates a bunch of stuff in
XSLT that it really really doesn't need to (although I must say that I
do think that XPath 2.0 should have a simple conditional expression,
similar to Java's). The main reason is that XPath 2.0 is being
designed as much as possible to be
everything-that-XQuery-can-do-except-node-construction, which is in my
view a big big mistake.

Take a look at XPath 2.0 and then *please please please* write
comments to public-qt-comments@w3.org saying what you think. The WGs
seem to be mostly ignoring the concerns that various individuals have
raised about the direction XPath 2.0 is going; only loud opposition
from a lot of people has a hope of changing their minds.

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

Right. I'll note for people who haven't been following the thread that
you're designing a procedural language rather than a declarative
language. When designing func:function for EXSLT, we purposefully
chose func:result rather than func:return to avoid the procedural
assumptions that come to people's mind when you use "return", and XSLT
2.0 is adopting the same terminology.

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

Again, that doesn't fit in with the declarative paradigm. I was just
trying to describe to you the approach that XSLT 2.0 was taking to
"objects" 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'].

Yes, or you could use some other character rather than the '.', e.g.:

  $dur#years()
  $name#local-name()

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

Yes :) Funky, eh :)

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

Nope. What it does (or rather, what XPath 2.0 does) is incorporate a
for loop so that you can do, e.g.:

  sum( for $i in item
       return @price * @quantity )

Of course that's not the same thing (and you'll note that it's another
example of the duplication between XPath and XSLT 2.0), but it does
address the same use cases as higher-order functions do.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]