Subject: Re: [xsl] xslt/xpath 2.0 comments ( long ) From: "cutlass" <cutlass@xxxxxxxxxxx> Date: Wed, 16 Jan 2002 12:12:51 -0000 |
From: "Michael Kay" [comments snipped throughout] > Jim Fuller (cutlass): > Are you going to post a copy of this to xsl-editors (please)? done > 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 yes, its a logical and strong arguement to not duplicate functionality, but at some point either the requirements for XPATH, XQuery and XSLT will converge or diverge at some point. I have noticed that XSLT/XQUERY destiny are intrinsically tied at the moment, maybe its because a lot of requirements are the same ( and both have the ability to address 100% of the XQuery use cases )....... and if this happens we should nail our colors to the post of what name to use and just have the WG streamline itself and work as an entire group for this one thing. i am certain that things will go much quicker for XSLT 3.0 ( hehe, my personal choice for the name ) if convergance occurs. personally i see convergance, but the questions will only get answered in commercial implementations. so in the spirit of MS word allowing one to do the same thing 20 different ways, i have no problem with allowing both XPATH and XSLT to do the same thing, for the time being ( though this makes more work for the implementators ). > 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"/>) yes, and yes to Jeni's response.... hehe forgot we dont need named templates anymore..... > > '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?' > > 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. i really dont feel comfortable with the thought that 2 vendors are going to implement a particular 3rd party function in the same way to the point where we will want to have a facility to map these functions together. i like the idea of identifying a vendor's function vs. user function, but I agree with JT that the namespace in any event should be different > 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 using vendor function binds you to vendor implementation, what possibly you are saying is that an automatic function-available() call is being made whereby branching may occur.. > 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.) will employ time-space folding device and come up with a few and send to xsl-editors > > 14.6 Date-Time Format functions > > We decided administratively that since XSLT is concerned with producing > human-readable output, and XQuery isn't, we would handle this requirement this is reasonable assumption > 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. once again something that addresses most of the situations, i always thought of XSL-FO as the possible repository of such formating, yes we want to do it native within XSLT, but formating to me comes under XSL-FO. > > <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... hehe, yes yes > 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.) the point was unclear on my part, yes as a programmer i can create pipelines, but i see great potential of formalising something for an XSLT author, and this is attributed to the success of the Cocoon sitemap stuff; its more syntatic sugar as one can definately create pretty much well the same thing in Native XSLT. sometimes sugar helps with getting the concept across. > 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). yup > 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 no, i was unclear as always. > used (by some implementation-defined API) to locate the result tree in the keyword here is API, i would like to put the decision of serialization into the hand of the XSLT author. > 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. this is a great boon and a logical break point > > Another possible candidate is evaluate(), if we decide to include that. possibly the problem with evaluate is simply a matter of constraining its scope to the generation of Dynamic XPATH statements which takes up most of the use cases within XSLT. thx for the comments, jim fuller XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] xslt/xpath 2.0 comments (, Jeni Tennison | Thread | RE: [xsl] xslt/xpath 2.0 comments (, naha |
RE: [xsl] alternating bg colour in , Andrew Welch | Date | RE: [xsl] alternating bg colour in , Andrew Welch |
Month |