This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Modes and .//something (2 questions)


> In certain circumstances, there is an element that
> I would be inserting during transformation, that will
> have an attribute whose value is dependent on a certain
> characteristic of the entire input document. So I
> first need to look through the whole document to
> determine this characteristic, then go through it
> again to do the actual transformation.

What is this characteristic? It's very likely that you can test for it using
a single XPath expression, rather than requiring an XSLT-level operation.

If you do need to do it within an XSLT-level operation, do it within a
global <xsl:variable>, and the value of the variable at the end will tell
you whether the condition arose or not.

>
> To begin with, I am trying to do this with a mode
> for the first pass. But I suspect I am misunderstanding
> the nature of XSLT evaluation.
>
> Here are the first few templates of my stylesheet,
> (with an extension call removed from the second
> template, as it's too much detail to show here).
> I've put in the messages to try to figure out what's
> happening.
>
>
> <xsl:template match="/">
>      <xsl:message>Hello there</xsl:message>
>    <xsl:apply-templates mode="scanIDs"/>
>      <xsl:message>Between there</xsl:message>
>    <xsl:apply-templates/>
>      <xsl:message>Goodbye there</xsl:message>
> </xsl:template>
>
> <xsl:template mode="scanIDs" match=".//channel">
>    <xsl:message>Matched channels in scanIDs</xsl:message>
> </xsl:template>
>
> <xsl:template mode="scanIDs" match="*">
> <xsl:message>Other stuff</xsl:message>
> </xsl:template>
>
>
>
> The third template seemed to be necessary; before I
> added it I got some of the blanks and tabs in the
> input document, copied to the output, and I don't
> want anything copied in the first pass.

The third template matches the document element, and because it doesn't call
xsl:apply-templates, the children of this element are never processed in
scanIDs mode. To get rid of the extraneous text, instead add a template rule
for text nodes:

<xsl:template mode="scanIDs" match="text()"/>
> My questions are:
>
> a) I need to have the "scanIDs" finished before the
> no-mode templates run. Is it true that I cannot rely
> on what order the statements in the first template
> are executed? In that case I would have to use
> two XSLT processor invocations after all.

If the second pass uses information written to a variable during the first
pass, that establishes a dependency, which ensures they have to run
sequentially. If no information is passed from the first pass to the second,
they can run in parallel.
>
> b) There are a number of <channel> elements in my
> input documents. But I never see the message from
> my second template.

See above for explanation. Incidentally the patterns "channel" and
".//channel" are equivalent, they match exactly the same nodes (though they
have different priorities).

Mike Kay
Software AG
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]