Re: [xsl] [exsl] Draft 0.1 - call for comments

[Francis Norton <francis at redrice dot com>]

Jeni Tennison wrote:
> 
> Hi,
> 
> I've put together a draft document that summarises our recent
> discussions on user-defined extension functions written in XSLT at:
> 
>   http://www.jenitennison.com/xslt/exsl.html
> 
> Comments on it should be sent here, to XSL-List with [exsl] at the
> start of the subject line.
> 
Wow!

My interest is as a potential heavy user, rather than as an implementor,
so my comments which are basically focussed on making it as useful as
possible while keeping it as simple and attractive as possible to
implement, both in turns of coding and in terms of not having to make
unnecessarily heavy design or architecture decisions - but as I said, I
am not an implementor so I may need to be corrected here!

[Issue: Namespace] the proposed namespace seems fine to me.

[Issue: Wrapper] no to the wrapper - this would simply be pre-empting
the XSLT 1.1 or 2.0 spec, wouldn't it? Would there be any other benefit
to it? (But is there an argument for making exsl:function elements
top-level in order to make their global availability more like that of a
top-level xsl:param?)

[Issue: Conditions] I'm guessing that extensions to XPath syntax - other
than adding functions - might seem like a major scope expansion to some
potential implementors - I vote for allowing xsl:if and xsl:choose as
direct descendents of exsl:function, if that is the choice (sorry, I
didn't follow that discussion in detail)

[Issue: RTF error] shouldn't this be detectable at parse-time? If so,
I'd make it "unrecoverable" error, if not, not. Presumably we also need
to ban literal text and non-executable elements appearing inside
exsl:function but outside variable binding elements.

[Issue: Templates] I am inclined to ban calling of templates outside
variable binding elements, in support of parse-time trapping of RTF
generation.

[Issue: xsl:for-each] no strong opinion ...

[Issue: Arguments] I would favour xsl:param and positional passing, for
maximum compatibility and simplest implementation.

[Issue: Optional arguments] no to extension attribute to indicate
optionality - there's a bundle of data typing features coming down the
river, and I wouldn't want to pre-empt them unless there is a compelling
reason, which I don't see here.

[Issue: Argument error] yes to making this an error, especially if it
can be picked up at parse time.

[Issue: Argument types] No - same argument as for Optional Arguments,
only more so!

[Issue: exsl:return name] I'd find either intuitive.

[Issue: exsl:reference-of] damn - I didn't follow this one either - is
it not also possible to create node-sets?

[Issue: exsl:return parent] too ambiguous to allow exsl:return elements
outside exsl:function elements, unless someone contributes a compelling
use case. Ban 'em.

[Issue: Multiple exsl:return error] Why can't the values of multiple
exsl:return elements simply be unioned together as a node set?

[Issue: Return values] yes, I'd go the empty node set as the default
value - this issue caused me some grief when I was writing account
reports.

[Issue: exsl:return expressions] again, I vote against extending XPath
syntax without a really compelling reason. Let's keep the implementation
scope of this as tight as possible (but no tighter...)

[Issue: Arguments by name] I could live quite happily without this - it
would be fun to have, but not at the sacrifice of a single useful exsl
implementation.

[Issue: Dynamic calls] see [Issue: Arguments by name]

[Issue: exsl:node-set name] um, what's wrong with node-set()? Compatible
with existing implementation - or so compatible it might be confusing?

[Issue: exsl:node-set argument] I'd go restrictive if it's detectable at
parse-time, permissive if it's something that can only be detected at
run-time.

[Issue: exsl:if] if this is easy to implement, I'd say yes - it would
reduce the pressure to extend XPath at this stage, and make code
simpler.

[Issue: Type tests] well, if we're going to add any type functionality,
having it in this read-only area,for XPath 1.0 data types only, would
cause the least baggage. Is the string / node-set decidability problem
sufficiently hard to work round to justify this?

Many thanks Jeni, really great work.

Francis.

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