[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: something I'd really like in XSLT

Subject: Re: something I'd really like in XSLT
From: "bryan rasmussen" <rasmussen.bryan@xxxxxxxxx>
Date: Tue, 23 Jan 2007 13:54:26 +0100
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:

   <xsl:template match="b" priority="-1">
       <b-matched-in-principal />
   </xsl:template>

No as a general rule I want to run the match at the level I'm on, I tend to know that something may be matched below me but I don't know how it is matched. At any rate priority is not useful for most of the things I might need to do.


If an imported stylesheet has a similar match, it will not match the
above. The other way:

   <xsl:template match="b" priority="1">
       <b-matched-in-principal />
   </xsl:template>

will match if there is *not* the same match in any of the
imported/included stylesheets.

Of course, it depends on the other set priorities.

Yes this can be problematic.

> > Checks as to the level matched would also be helpful. Obviously could > implement something like this with apply-imports or nex-match if all > stylesheets in a framework could be expected to apply the method.

What do you mean with "level matched". Do you mean the order of
precedence? You can calculate that (but that number is of little use in
run time, I think).

I agree it is little use in most cases in runtime. I was just thinking of some rather complicated frameworks I have for doing matches as I was walking about the office drinking my coffee and I thought damn if only I could.




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]".

Lots of work. I would like an easier way to do it (which I guess is the normal complaint)



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


<!--this matches to the priority example--> <xsl:template match="x:a"> <xsl:variable name="ismatched"> <xsl:apply-templates select="self::*" mode="ismatched"/> </xsl:variable> <xsl:choose> <xsl:when test="ns:node-set($ismatched)/m:matchinformation"> <h1>The information <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>



<!--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:a"> <p>from exampleimports a <xsl:value-of select="."/></p> </xsl:template>

<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>


now this is of course not a useful example but we can see how the first example template matches normal priority operation (but the running of the template is not affected by the priority rules of the template, basically the execution of the template is now affected by the priority of how one matches the same element in the ismatched mode) with the exception that I can switch execution dependent on if there is an import that matches. I can of course do this by running xsl:apply-imports and testing if there is any content of my variable but it seems somewhat fragile to say the least.

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.




Cheers, Bryan Rasmussen

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.