Subject: Re: [xsl] RDDL as a delivery vehicle for XSLT extensions? From: "Steve Muench" <Steve.Muench@xxxxxxxxxx> Date: Sat, 3 Mar 2001 16:08:09 -0800 |
| On Fri, 2 Mar 2001, Steve Muench wrote: | > | Yes, all the hassle could have been avoided if I'd put the xsl:script | > | in an imported stylesheet. | > | > Correct. So the only thing you would have in your 50 stylesheets is: | > | > <xsl:import href="common-date-functions.xsl"/> | > | > or, you might depend on some web-hosted version of the library stylesheet, | > at your discretion. | > | > <xsl:import href="http://somesite.org/xslt/ext/common-date-functions.xsl"/> | > | > And so you have the same simplicity of maintenance as the other proposal. | | Not quite so fast. | | 1) Now you need to now syncronize all of the | prefixes across your organizaiton. Clark, I think Jeni's response to your other mail hopefully cleared up this confusion. The prefix is nothing more than a local nickname for the namespace URI. There is nothing sacred about the nickname, and you can use any nickname you want. The only thing that's important is the namespace URI for which it's a shortcut. It's only a vehicle to avoid typing. Imagine writing an XSLT stylesheet like this: <{http://www.w3.org/1999/XSL/Transform}:stylesheet version="1.0"> <{http://www.w3.org/1999/XSL/Transform}:template match="/"> <{http://www.w3.org/1999/XSL/Transform}:for-each select="foo"> <{http://www.w3.org/1999/XSL/Transform}:copy-of select"."/> </{http://www.w3.org/1999/XSL/Transform}:for-each> </{http://www.w3.org/1999/XSL/Transform}:template </{http://www.w3.org/1999/XSL/Transform}:stylesheet> To save all that typing, we assign a nickname to represent the namespace uri: <x:stylesheet xmlns:aaa="http://www.w3.org/1999/XSL/Transform" version="1.0"> <x:template match="/"> <x:for-each select="foo"> <x:copy-of select"."/> </x:for-each> </x:template </x:stylesheet> The XSLT processor recognizes <x:template> because the prefix "x" maps in the current scope to the unique URI for the XSLT 1.0 spec http://www.w3.org/1999/XSL/Transform. | 2) You are still limited to implementations in the | languages referenced in this imported style-sheet | since there are no other resolution mechanisms. Correct. The ability to reference this imported stylesheet from a central, agreed-upon web resource would mean that "someone else" could update the definition of supported languages for the "library stylesheet" and your stylesheets would never need to know. All I'm trying to point out is that the current <xsl:script> mechanism contains all of the ingredients necessary to push off the maintenance of that "library stylesheet containing <xsl:script> bindings to some central place, or it can be locally read from your own disk, totally up to what URI you use in your <xsl:import> statement. If you're using the JAXP 1.1 TRAX api to process the stylesheet, I believe you can provide your own entity resolvers so that your stylesheet might contain the URL to a centrally-maintained library stylesheet but your "smart resolver" might realize that it has the library stylesheet in a cache locally already. My point is that the current proposal has been engineered to be no more complicated than necessary to enable most of the scenarios that you are thinking about. | The question is, why can't the "script" element belong to | another, non-XSLT specification. : | If it is just an XSLT specification then every | other W3C spec which needs extension function binding will go | out and invent their own mechansim rather than re-use a | common mechanism. The way this has worked in the past is that one working group approaches another and says, "Hey, we want to use part of what you're doing" This is how XPath got "factored out" of XSLT to be shared by XPointer and XSLT (also by XQuery now). If this dynamic were in set in motion, it might make sense to factor it out in this way. ______________________________________________________________ Steve Muench, Lead XML Evangelist & Consulting Product Manager BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG Author "Building Oracle XML Applications", O'Reilly http://www.oreilly.com/catalog/orxmlapp/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] RDDL as a delivery vehicl, Clark C. Evans | Thread | Re: [xsl] RDDL as a delivery vehicl, Clark C. Evans |
Re: [xsl] Working with QNames in va, Simon Fell | Date | Re: [xsl] re: generation of qnames/, Steve Muench |
Month |