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]

Re: Functional programming in XSLT


Hi Mike,

> Secondly, I don't like treating multiple exsl:result's as a
> "recoverable error". I can't think of too many existing cases in
> XSLT 1.0 where people are going to write stylesheets that depend on
> errors being recovered by one processor, where they are going to
> have considerable difficulty fixing the error if another processor
> chooses not to recover from it.
>
> I still prefer having a static constraint on where <exsl:return> can
> appear, but if you can't live with that, have a strict rule that
> only one may be instantiated.

I'm just putting the finishing touches on a new version of EXSLT -
Functions that makes the changes that you suggested and Steve
supported, and I've come up against the question about whether to
specify that exsl:return actually terminates the function or not. I
thought I'd take a look to see how you'd done it in Saxon. I used the
following test:

<saxon:function name="my:func">
   <xsl:if test="true()">
      <saxon:return select="false()" />
   </xsl:if>
   <xsl:if test="true()">
      <saxon:return select="true()" />
   </xsl:if>
   <xsl:message>Doesn't terminate</xsl:message>
</saxon:function>

This function meets the static constraints on saxon:return and Instant
Saxon 6.2 runs it without complaint. I was expecting it to return
false and to not receive a message (the documentation I have says:
"Instantiating a saxon:return element causes exit from the call of the
enclosing saxon:function."). But in fact the result of calling
my:func() is true (the value of the last saxon:return that's
instantiated) and the message comes up, so I guess this means that
saxon:return doesn't terminate the function.

Perhaps this is just a bug in version 6.2, but I was thinking: surely
it wouldn't matter if more than one exsl:return element is
instantiated if the function is terminated on the instantiation of the
exsl:return element. Rather than it being an error, we can just say it
never happens.

But perhaps it's difficult to implement something that terminates on
the instantiation of a particular instruction, given that this is
somewhat divergent from how instantiating instructions works in other
situations?

In that case, would it be easier to implement/understand if we said
that exsl:return cannot be instantiated more than once, but other
instructions can be instantiated after exsl:return?

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]