Subject: RE: [xsl] xslt/xpath 2.0 comments ( long ) From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx> Date: Wed, 16 Jan 2002 10:38:03 -0000 |
Jim Fuller (cutlass): Are you going to post a copy of this to xsl-editors (please)? Some observations attached. Mike Kay > > ------------------------------------------------ > issue 1.2: a look at the transquery method > www.transquery.org ) currently > being proposed by Evan Lenz addresses this issue > ------------------------------------------------ > Jeni Tennison proposal of dealing with 'sequence constructors > ' ( xsl:item > and amended xsl:function syntax ) sends my spidey sense > reeling, not quite > sure if i can vocalise my concern. > I foresee that sequences will be a 'unique' concept for > people to adjust or > learn( just after they've learned how to deal with trees) , i > also foresee > that the new XPATH syntax, though wildly expressive; will > once again make it difficult for newbies. Well, obviously any new feature is also something new to learn, and this is something where we have to get the balance right. Because we've provided sequences as an extension of the 1.0 node-sets, one can argue that we haven't actually increased the number of concepts as much as it would seem. Jeni's argument that we could do sequence manipulation in XSLT rather than in XPath is something that we'll revisit in the WG. Personally, I would hate to duplicate the functionality at both levels, and I'd like to have as much syntax shared with XQuery as possible so long as it doesn't compromise the design integrity of the language. [comments snipped] > > 7.1.1 Passing Parameters to Templates > > > ' Issue (add-type-to-with-param): Should we add a type attribute to > xsl:with-param, for symmetry with xsl:variable and xsl:param? ' > > +1 to this, makes sense > > ' Issue (with-param-verbosity): Should we introduce an > alternative and less > verbose syntax for passing parameters when invoking a template? ' > > I was under the impression that one would be able to call a > template using > function like syntax; my:template(param,param,...) No, there's no proposal to do that. Arguably, named templates are now redundant, since you can always replace a named template with a function (that returns a temporary tree), and call it as <xsl:copy-of select="my:function(params)"/>; this would suggest that the case for introducing a less verbose syntax for call-template is now rather weaker. (I think the idea behind the issue was to allow a template named "my:tmpl" with parameters x, y, and z to be called as <my:tmpl x="1" y="2" z="$v+3"/>) > > otherwise, is this where we could abuse sequences and place > the param in a > sequence? > > <xsl:call-template name="my:template"> > <xsl:with-param select="($x,$y)"/> > </xsl:call-template> > > which may mean an option with <xsl:with-param/> would have > no-name, and the > sequence represents the physical order of <xsl:param/> within function > template. > > ------------------------------------------------ > 7.3.1 Defining a Stylesheet Function > > 'Issue (user-functions-vs-vendor-functions): Should > user-defined functions > override vendor-defined functions of the same name, as > specified here, or > should it be the other way around?' > > the vendor, at the very least, should implement their function with a > namespace attatched, why would there be any overloading of > functions, which > could also be yet another bad thing with respect to security. > > If a user wanted to override saxon:evaluate() with their own > function named > saxon:evaluate(), i think an error should be thrown. That would imply that if the user writes an emulation of saxon:evaluate in order to allow a stylesheet written for Saxon to run under (say) Sablotron, then the stylesheet containing this emulation will fail when it's run under Saxon. The alternatives: choosing the vendor's version of saxon:evaluate() in preference to the user's version means that the stylesheet may produce different results when run under different processors. In theory, a vendor could return anything he liked in response to any extension function call by arguing that he was calling his own implementation (sounds perverse, but these things happen when it comes to running benchmarks and conformance tests). Choosing the user's version in preference means that instead of emulating saxon:evaluate(), the user would have to write a wrapper function that makes the decision whether to call user code or to call the vendor's version. This to me seems the cleanest solution. > > ------------------------------------------------ > 13.3 Examples of Grouping > > typographical error in xsl:value statement within 1st solution > > <xsl:value-of select="current-group()/@name" separator=","> > > should have closed ending > > <xsl:value-of select="current-group()/@name" separator=","/> Thanks for spotting this. > ------------------------------------------------ > > +1 should allow grouping with other datatypes, this is not > such a serious > point for now, but i can see in the future an expansion of > datatypes being > included ( possibly all X Schema, etc ), using grouping on > dates would be > immediately useful. > ------------------------------------------------ > > 14.5 Dynamic XPath Expressions > > ++1 > > definately require an eval() function along the lines of the > currentsaxon:eval(); dont care where it lives... and in > general this is > no-brainer, admittedly its something that appeals to the less > experienced user, but hey why not ? We really need this kind of comment to go to xsl-editors; preferably with some reasoning as to why you need this function. (Though I think we already recognize that it's a useful capability for many users; the concerns are about implementability in some environments, and also about potential misuse of the facility.) > > ------------------------------------------------ > > 14.6 Date-Time Format functions > > > This is probably best served as within XPATH, instead of > XSLT, which i believe is being proposed. Though i would like to see > something > lightweight and address 80% of the problems, then the > xsl:number monster. We decided administratively that since XSLT is concerned with producing human-readable output, and XQuery isn't, we would handle this requirement within the XSL WG for the moment, and then consider moving the solution into the shared function library later. But the solution is likely to be a simple function that can be called from XPath expressions. > > ------------------------------------------------ > <xsl:apply-tranformation/ > > originally suggested by David Carlisle 10 Jan 2002 Actually it's been suggested by various people in various forms over a period of time... > > I always thought that xsl:transform would be a better term, > but keeping( and > its used up already ) in step with the other 'apply' terms > > something like; > > <xsl:apply-transform source="$y" stylesheet="$x"/> > with assoc. function form; apply-transform($y,$x) > > having this would allow for sophisticated pipelines of > processing to be > created, sort of what goes on with some xslt app engines like > Cocoon and > AxKit > > this gives the opportunity for getting away from the serialisation to > physical file model that is being introduced/forced with the > xsl:destination > and > xsl:result:document. The whole idea of xsl:destination and xsl:result-document was to separate the description of the result tree from any concerns about serialization. If it's picked up in the right way by implementations (and by the JAXP API, for example), then it enables a pipeline of transformations to be constructed by the application (using one stylesheet for each transformation) in which the result trees from one transformation can be referenced by URI independently of their format and independently of whether or not they have been serialized. (But this concept of enabling a pipeline of transformations to be controlled from the application doesn't diminish the potential value of being able to invoke a transformation from within a stylesheet.) > > ------------------------------------------------ > > 17.1 The Principal Result Tree > > 'Issue (destination-element-name): Is it possible to find a > better name for > the xsl:destination element? The name xsl:principal-result has been > suggested.' > > I am not convinved about the inclusion of a seperate element > is necc., could > this not be dealt with as an attribute to either xsl:stylesheet or > xsl:output ? The aim here is to separate things that concern the result tree from things that concern serialization. (I can see us adding other attributes concerning the result tree, for example something that says it should be validated against a particular schema). > > Though this function and xsl:result-document are useful they > constrain to > the creation of physical files, with no abstraction for > future pipelining to > lets say an xml repository, which i suspect will have > something to do with > either a new attribute on <xsl:output/>..... Perhaps you are assuming that because these elements assign a URI to the result tree, the result tree must be stored on disk and therefore must be serialized? That's an incorrect assumption. The idea is that the URI can be used (by some implementation-defined API) to locate the result tree in memory. Unlike the XSLT 1.1 facility, and many current implementations, the idea is that the processor should be able to produce multiple result trees even if it doesn't support serialization. > > ------------------------------------------------ > > 19 Conformance > > 'Issue (conformance-modules): Should we introduce multiple conformance > levels or modules, recognizing that serialization is a separate > specification to which processors may or may not conform?' > > I was originally all for something like this; but now XPATH > dependancy and > some radical core changes within XSLT make it hard to see > where the breaks > occur. Maybe instead of identifying some of the more > experimental aspects as > non-core or advanced functions....hmmm One candidate for a separate conformance module is serialization. Instead of making the whole serialization spec use the word "should" rather than "must", it would be better to say that implementations can choose whether to implement serialization, but if they do, they must implement it as described. Another possible candidate is evaluate(), if we decide to include that. > > I am glad that the language binding has been recognized as a different > kettle of fish and requires a seperate spec.... has this WG > been formed yet? No, I don't think anyone is actively pursuing this. I'd personally like to see a Java binding in a future version of JAXP. The binding for 2.0 is going to be considerably more complex than the 1.1 binding because of the increase in the number of data types. Mike Kay XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] xslt/xpath 2.0 comments ( lon, cutlass | Thread | Re: [xsl] xslt/xpath 2.0 comments (, Jeni Tennison |
[xsl] Higher-Order Functions in XPa, Dimitre Novatchev | Date | RE: [xsl] Function arguments (was r, Michael Kay |
Month |