[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Reverse selecting match statements - a not matching?

Subject: Re: [xsl] Reverse selecting match statements - a not matching?
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 26 May 2012 16:12:32 -0400

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 and 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 replicating the <para> element processing for every mode that might be involved with para elements.

The specific circumstance that I have is this 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 available 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.

Danny Vint

Panoramic Photography

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

Current Thread