Subject: Re: [xsl] [exsl] Draft 0.1 - call for comments From: Francis Norton <francis@xxxxxxxxxxx> Date: Mon, 26 Feb 2001 00:07:15 +0000 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] [exsl] Re: Draft 0.1 - ca, Jeni Tennison | Thread | Re: [xsl] [exsl] Draft 0.1 - call f, Jeni Tennison |
Re: [xsl] url encoding of ampersand, Mike Brown | Date | [xsl] Q on XML 2 XML/plain text, Rosa I-Ting Cheng |
Month |