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

Re: Reverse selecting match statements - a not matchin

Subject: Re: Reverse selecting match statements - a not matching?
From: Vasu Chakkera <vasucv@xxxxxxxxx>
Date: Sat, 26 May 2012 23:44:08 +0100
Re:  Reverse selecting match statements - a not matchin
Generally depending on what you are trying to achieve, a couple of
options can be exercised/

Case 1

You have some templates defined for the multimedia | otherunwanted ..
So there are templates in your stylesheets which actually do an
apply-templates to the multimedia | otherunwanted  and *will* process
the elements. However some other templates in your stylesheet may want
to process everything except the multimedia | otherunwanted. In this
case.. the best thing to do is to
   1. <xsl:apply-templates select="*"/>  in the templates where you
intend to *process* all elements including multimedia | otherunwanted
   2.  <xsl:apply-templates select="*[not(self::multimedia |
self::otherunwanted)]"/> in the templates where you want to *ignore*
the multimedia | otherunwanted.

Case 2

This is the case where you only have one place in the stylesheet,
where the apply-templates is called , and then you *definitely* want
to ignore multimedia | otherunwanted for the *entire* life of the

In this case, we could do something like  <xsl:apply-templates select="*"/>

and then create empty templates for the ones you want to ignore.

<xsl:template match = "multimedia | otherunwanted "/>

This kind of works well if there is some kind of delegation model
applied to the stylesheets ... So if the file where apply-template is
written is different from the place we define templates.. So we decide
what to do when it comes to it. May be *not* applying templates to the
nodes we dont want is more efficient than applying templates to "*"
and closing doors on the nodes we dont want processed. Could be left
to the convenience of the situation...( and a bit clutter free
apply-templates statement )


On 26 May 2012 21:12, G. Ken Holman <gkholman@xxxxxxxxxxxxxxxxxxxx> wrote:
> It is handy you have an explicit list of the elements you do not want
> applied.
> If you are using XSLT 2 you have the "except" operator available:
>  <xsl:apply-templates select="* except (multimedia | otherunwanted  )"/>
> It can be done in XSLT 1 along the lines of:
>  <xsl:apply-templates select="*[not(self::multimedia |
> self::otherunwanted)]"
> I hope this helps.
> . . . . . . . . Ken
> At 2012-05-26 13:07 -0700, Dan Vint wrote:
>> So I have an element that has a variety of child elements. For the most
>> part I can just let these pass through and be handled with default
>> selection/processing. So a generic <xsl:apply-templates/> works for me.
>> The problem is that there are a few elements in that list that I don't
>> want processed. So I would like to just list the elements not to select
>> still let the others pass through.
>> The only way I can see to handle this is to add a mode statement to the
>> apply-templates call and then just stop the processing of the selected
>> elements that I don't want matched. I would like to avoid adding mode
>> statements to these calls and then all the default processing because many
>> of the elements are used all over the place. I'm trying to avoid
>> the <para> element processing for every mode that might be involved with
>> para elements.
>> The specific circumstance that I have is this content:
>> <content>
>> <step1>
>>        <para>...</para>
>>        <step2>...</step2>
>>          <step2>...</step2>
>> <step1>
>> <step1>
>>        <para>...<para>
>>        <multimedia>...</multimedia>
>>        <step2>...</step2>
>>          <step2>...</step2>
>> <step1>
>> </content>
>> So for actually both the step1 and step2 elements (and further levels), I
>> don't have a wrapping construct that allows me to trigger an html <ol>
>> element to wrap them. Before the step2 there can be a long list of
>> elements that I would prefer to not list everything from the DTD if I can
>> avoid it. Over time the DTD may change and I would have to add these
>> elements to the list.
>> For the step2 elements, I need to do a check to generate the wrapping <ol>
>> to make these an HTML list. I suppose in this case another option would be
>> to number the list elements myself and not use the standard html ol/li
>> element constructs.
>> ..dan
>> Danny Vint
>> Panoramic Photography
>> http://www.dvint.com
>> voice: 619-938-3610
> --
> Public XSLT, XSL-FO, UBL and code list classes in Europe -- Oct 2012
> Contact us for world-wide XML consulting and instructor-led training
> Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
> Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/
> G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
> Google+ profile: https://plus.google.com/116832879756988317389/about
> Legal business disclaimers:    http://www.CraneSoftwrights.com/legal

Vasu Chakkera
NodeLogic Limited

Current Thread


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.
First Name
Last Name
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.