[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: something I'd really like in XSLT
If you mean it such that a certain template should only be called *if* it is not previously matched by another template in some imported or included stylesheet, however deep, you can use priorities. Use a low prio in your principal stylesheet and it will only be matched *if* it does not have a match in any of the imported stylesheets. Like this:
If an imported stylesheet has a similar match, it will not match the above. The other way: Yes this can be problematic.
If I remember my lessons correctly, the precedence is calculated by means of priority, based on how specific your match is. Like "*" has less prio then "nodenamehere", which has less prio then "/nodenamehere" which has less prio then "/nodenamehere[predicatehere]".
But perhaps I misunderstood your question/request? Can you give a coded example of how you see these added features? okay here is an example in XSLT 1.0 fragment doing it: importer XSL
</p> </xsl:otherwise> </xsl:choose> </xsl:template> <!--this allows matching if the match is a specific match on the element--> <xsl:template match="x:b"> <xsl:variable name="ismatched"> <xsl:apply-templates select="self::*" mode="ismatched"/> </xsl:variable> <xsl:choose> <xsl:when test="ns:node-set($ismatched)/m:matchinformation/m:source/m:matches/m:specificmatch[@localname='b']"> <h1>The information from specific element match <xsl:value-of select="ns:node-set($ismatched)/m:matchinformation/m:source/@name"/></h1> <xsl:apply-imports/> </xsl:when> <xsl:otherwise> <p><xsl:value-of select="."/> </p> </xsl:otherwise> </xsl:choose> </xsl:template> and exampleimport.xsl
<xsl:template match="x:b"> <p>from exampleimports b not value of select</p> </xsl:template> <xsl:template match="x:*"> <p>No no no</p> </xsl:template> <xsl:template match="x:*" mode="ismatched"> <m:matchinformation namespace="http://www.example.org"> <m:source name="exampleimport.xsl"> <m:outputformat type="xml"/> <m:matches> <m:genericmatch type="element"/> <m:specificmatch type="element" localname="b"> </m:specificmatch> <m:specificmatch type="element" localname="a"> </m:specificmatch> </m:matches> </m:source> </m:matchinformation> </xsl:template> and example.xml <?xml version='1.0' encoding='UTF-8'?><document xmlns:x="http://www.example.org" <x:a>the document</x:a> <x:b>the document</x:b> </document>
the second allows me to run if there is a specifc match to my element instead of a generic match. The above is however very fragile because I cannot expect to have a system of stylesheets that does the following -stylesheet X checks status of matches from Stylesheet Y stylesheet Y checks status of matches from Stylesheet Z Stylesheet Z using the above method, because if I have a match in the x namespace for the mode ismatched in Y and Z then Y must set its priority to -1 to default to Z to get Z's information. Then X must set priority to -2. I get no closer to being able to get the implicit import order information using this method. I suppose that one could do this kind of thing using next-match, but I suppose what I would like is a boolean ismatched(xpathgoeshere,modegoeshere), modegoeshere is not required obviously if ismatched(xpathgoeshere) do stuff applyimports or next match /end if then one could have also currentmatch() and highermatch(), higher match is a boolean, is there a match that is more specific in my import order that is being overriden by my priority? I know this probably sounds very abstract and grasping at problems when there shouldn't be any, but I do have some frameworks where I would benefit from being able to do this kind of analysis. And if anyone can think of some easier XSL-T 2.0 solutions for the problem or testing frameworks that can handle it please come with the suggestions. One usage I am looking at is as follows: in a repository comprising possibly thousands of namespaces, with the idea that namespaces can be reused in other higher level namespaces, the problem of writing a stylesheet system for presentation of these variant namespaces becomes difficult. I thought this kind of thing could be useful for my task, however what I will probably end up doing instead is building tools for generation and analysis of stylesheets handling the various namespaces and not providing runtime branching of displays.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|