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

[Vasu Chakkera <vasucv@xxxxxxxxx>]

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
use
   1. <xsl:apply-templates select="*"/>  in the templates where you
intend to *process* all elements including multimedia | otherunwanted
and
   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
stylesheet,

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 )

Vasu

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
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:
>> <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
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.
>>
>> ..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
Oxford
www.node-logic.com
==============