[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] [exsl] Draft 0.1 - call f, Jeni Tennison | Thread | Re: [xsl] [exsl] Draft 0.1 - call f, Jeni Tennison |
Re: [xsl] sort question, Jeni Tennison | Date | [xsl] XML-to-XML question, Wolfgang Bogacz |
Month |