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

Subject: Re: [xsl] [exsl] Draft 0.1 - call for comments
From: David Carlisle <davidc@xxxxxxxxx>
Date: Mon, 26 Feb 2001 18:57:28 GMT
<exsl:function
   name = QName>
   <!-- Content: (xsl:param*,
                  (xsl:variable | xsl:if | xsl:choose | xsl:message)*,
		  (exsl:return, xsl:fallback?)? -->
</exsl:function>
	

Personally I think that this highly restricted version of XSL will end
up making things confusing. If you're going to allow XSL written
functions I'd allow everything that's allowed within a template.

(You could disallow the creation of nodes into the result tree,
although personally (since I haven't got to implement this:-)
I'd allow the creation of nodes, with the restriction (similar
to the restriction on xsl:attribute) that once you have created a node
you can't have an exsl:return. An exsl:return-less function would
return the constructed RTF ie

<exsl:function name="a:b">
 <exsl:param name="x"/>
 <hello/><world/>
</exsl:function>

would be the same as


<exsl:function name="a:b">
 <exsl:param name="x"/>
 <xsl:variable name="y">
  <hello/><world/>
 </xsl:variable>
 <exsl:return select="$y"/>
</exsl:function>

or i suppose

<exsl:function name="a:b">
 <exsl:param name="x"/>
 <exsl:return>
  <hello/><world/>
 </exsl:return>
</exsl:function>


In the case that you want the function to create an rtf (aka 1.1
generated node set) the model of having the generated thingy just being
the body of the relevant binding construct seems more natural to me.

(I've also moved the param element into the exsl namespace, bit wary of
overloading xsl:param for this as it's not being used with standard xsl
constructs, and in particular it isn't being paired with with-param, but
rather it's setting up a positional context. )


> Issue: Wrapper - should there be a wrapper element to contain the
> exsl:function elements in a document?  

Not if this is an XSLT 1.0 extension.
For XSLT 1.0 you might want to look at what would be involved with
merging this wth xsl:script.

> Note: the rules on resolving qualified names entail that if no prefix
> is defined, the namespace URI resolves to the null namespace. Thus, it
> is an error if the qualified name specified does not have a prefix.  

Hmm does the XSLT 2.0 requirement to offer a mechanism for specifying the 
namespace for unprefixed names in XPath affect function (and mode and
variable and .. ) names as well? (Not that that affects your paper, I'm
just musing)




> Issue: RTF error - should generating result nodes be an unrecoverable error? 

see above:-)

> Issue: Templates - should it be possible to call or apply templates within 
I'd allow everything.

> Issue: xsl:for-each - should xsl:for-each be allowed 

ditto

> Issue: Arguments - should arguments be specified with the xsl:param
> element or through attributes on exsl:function?  
exsl:param
or maybe better as they are positional arguments rather than named
parameters 
exsl:argument


> Issue: Optional arguments - should there be an extension attribute on
> xsl:param that indicates whether an argument is optional?  

If the element was out of xsl namespace, the attribute could be
unprefixed but yes you might want such a thing, although it only
makes sense to have things being optional "from the right" and
so it might be simpler to just mandate that everything is optional
an that a default is always specified (as is the case with named templates)

> An XSLT processor must not signal an error if an extension function is
> called with fewer arguments than there are parameters defined for the
> extension function 

If you say this (which might be reasonable) then every argument is
optional, so I'm not sure I understand the issue quoted above.

> 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

> Issue: Argument types - should there be an extension attribute on
> xsl:param that indicates the value type of an argument?  

no



> Issue: exsl:return parent - should the use of exsl:return be
> restricted to within exsl:function or is this too restrictive? Are
> there any other places where exsl:return might be useful?  

depends whether you want to ensure exsl:return is explicitly a child
of exsl:function or just instanciated at run time eg in a called
template. (As discussed on the list with for-each, of you start
allowing this you have to be careful  how to ban multiple concurrent 
instantiations of the return instruction.



><exsl:function name="my:func1">
>   <xsl:if test=". = 'yes'">
>      <exsl:return select="true()" />
>   </xsl:if>
>   <exsl:return select="false()" />
></exsl:function>

If you go this far you are already requirng a run time check so you may
as well go the whole hog and allow exsl:return  to be in another
template, perhaps?

> If no exsl:return element is instantiated during the execution of a
> function, the return value for the function is the empty string ('').  

see above for a possible alternative



> Issue: exsl:return expressions - should the select attribute on
> exsl:return hold an extended XPath syntax that includes things such as
> conditional constructs?  

I don't know what you have in mind here, but probably, no.



> Extension functions defined using exsl:function can be called in the
> same way as XPath functions. Calling extension functions in this way
> causes arguments to be passed by position.

I think this should say that functions defined via exsl:function
should be added to the current XPath context. Thus the following
two issues re calling syntax are moot. (They may be desirable features
but they would need to apply to any XPath extension function not just
these ones)


> Issue: exsl:if - should this specification define an exsl:if function
> for conditional processing that doesn't involve evaluating both the
> true and false parts?  

It would be nice but I'm not sure it can be done (as a pure XPath 1.0
extension)


> Issue: exsl:if - should this specification define an exsl:if function
> for conditional processing that doesn't involve evaluating both the
> true and false parts?  

You'll need something like that, I think.



> com:eval
Maybe it's just because I've a headache, and no voice, but this one
eludes me at present, I'm sure it's doing something jolly useful
but....


> Function: node-set num:highest(node-set, string?) 

I'd call this max (a name you'd stolen earlier)

David

(As usual in these things, comments always look bad, because there's no
point in commenting on the god bits:-)

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.star.net.uk/stats.asp

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


Current Thread