This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: [exsl] Draft 0.1 - call for comments
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] [exsl] Draft 0.1 - call for comments
- From: Uche Ogbuji <uche dot ogbuji at fourthought dot com>
- Date: Thu, 01 Mar 2001 00:43:27 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
Thanks so much for the brilliant work, Jeni. An excellent document. Here are
my few comments.
"Issue: Namespace - what namespace should be used for these extension
elements/functions? Possibility:
http://xmlns.opentechnology.org/xslt-extensions/common"
I'll set up a RDDL page for this namespace this week.
"<exsl:function
name = QName>
<!-- Content: (xsl:param*,
(xsl:variable | xsl:if | xsl:choose | xsl:message)*,
(exsl:return, xsl:fallback?)? -->
</exsl:function>"
Looks as if "exsl:return" beat out "exsl:result". Yuck. Oh well, maybe I can
come up with a brilliant argument to sway the electorate.
"Issue: RTF error - should generating result nodes be an unrecoverable error? "
I like it as you have it now: error or ignore the nodes.
"Issue: xsl:for-each - should xsl:for-each be allowed within exsl:function
outside variable-binding elements? It would ease the return of node sets
created (a) from other documents or (b) involving sorting the node set in
other than document order. This is achievable by building an RTF with IDs
referring to the relevant nodes instead. "
I think for-each should be allowed for the reasons you suggest.
"Issue: Argument error - should trying to pass more arguments than there are
xsl:param elements be considered an error? Should it be an unrecoverable
error? "
Yes, I think it should be an unrecoverable error.
"Issue: exsl:return name - should exsl:return be called exsl:result instead?"
No points for guessing what I think.
"Issue: exsl:reference-of - should it be possible to return node sets by
building them up gradually through an extension element such as
exsl:reference-of? It would ease the return of multiple nodes from a function.
This is achievable by building an RTF with IDs pointing to the relevant nodes
instead."
I've been watching the reference-of discussion with interest. There would be
no problem implementing this for 4XSLT, but value vs reference semantics is
such a variable matter between languages that I wonder whether it's
impractical for some implementers.
"Issue: Dynamic calls - should there be a way to dynamically determine the
name of the function being called?"
Using separate arguments Steve and Andrew have convinced me that we should
defer this feature.
"Issue: Type tests - should this specification define functions to test the
type of values passed as parameters? Several XPath functions allow an
argument to be either a string or a node set, but treating a string as a node
set will cause an error and there's no way to detect whether a variable value
is actually a string or a node set."
Oh boy. Pet peeve of mine. I don't think there should be type tests. I'm of
the strong opinion that it is a mistake that so many languages provide special
status to data type among factors in program correctness.
As for the reference function implementations, great stuff.
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +1 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list