[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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 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 ==============
|
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
|