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

RE: Copy-per-default

Subject: RE: Copy-per-default
From: Fredrik Bengtsson <Fredrik.Bengtsson@xxxxxxxxxxxx>
Date: Thu, 21 Apr 2011 08:11:15 +0000
RE:  Copy-per-default
(sorry, fat fingers)

... it would make the transform larger. So for this particular application I
will stick to the whitelisting approach where I clearly state exactly every
step that I expect to happen along the way, and nothing else. Then again, I am
not very experienced in these matters and as my understanding matures I'll
probably try to reevaluate this.

Thanks for your help!

/F


-----Original Message-----
From: Fredrik Bengtsson
Sent: den 21 april 2011 10:09
To: 'xsl-list@xxxxxxxxxxxxxxxxxxxxxx'
Subject: RE:  Copy-per-default

Yeah, things work great now, albeit with a caveat or two (see my e-mail to
Florent Georges).

I understand the point you are making regarding the *|/ template. It has its
benefits, but I am sort of a control freak or perfectionist if you will. For
my part, I'd really prefer "whitelisting" the things I want to happen and
being meticulous in the pattern design. Someone suggested adding a "null"
template for d:book/d:info specifically instead of for *, but that'd be a form
of blacklisting and relies on me knowing any and all possible subnode types
today and for all time to come. Not only could that lead to unforeseen
consequences (text garbage in the fo), it would make the0020

-----Original Message-----
From: Brandon Ibach [mailto:brandon.ibach@xxxxxxxxxxxxxxxxxxx]
Sent: den 21 april 2011 01:38
To: xsl-list
Subject: Re:  Copy-per-default

I think, over time, you'll find it's actually quite intuitive.

Just to clarify the defaults, the values of attributes are output, but
only if you explicitly apply templates to the attributes, as the
default for elements (and the root node) is to apply templates (in the
current mode, if any) to just the child nodes, and attributes are not
children.

So, you could create the empty template with match="*" (no need for
@*, as noted above), but I think you'll find in most cases that this
short-circuits much of the power and elegance of XSLT.  Of course,
it's hard for me to say what's right in your case, but it seems likely
that you'll be better off with more selective empty templates, such as
one with match="book/info", if you want to suppress that whole
hierarchy.  That single template will cover the whole thing, since
elements further down will never have templates applied to them.

-Brandon :)


On Wed, Apr 20, 2011 at 6:48 PM, Fredrik Bengtsson
<Fredrik.Bengtsson@xxxxxxxxxxxx> wrote:
> Wow, now come to think of it I DID stop to think at one time why I did not
have to write a specific rule for text(). This explains it. Well that behavior
is fine, I'll keep that. But getting the values of @* and recursing into *|/
are a downright disaster in my case!
>
> What I need to express is that whenever a node is examined that does not
have an explicit matching template (well, except the one template that
achieves just that, of course), then that node is discarded entirely and is
NOT descended into, i.e. its children are ignored too. So ... if I understand
this correctly, I should be able to get what I want just by adding
>
> <xsl:template match="*|@*" />
>
> I'll try that at work tomorrow.
>
> As an aside - wow, that combination of rules you listed below sure do give
strange results sometimes. <book> has an entire <info> hierarchy below it, and
all of its textual content is copied into the output in one big mess, but with
all of the actual elements stripped out. That's just ... Well, now it makes
sense anyway, thanks for informing me.
>
> /F
>
> -----Original Message-----
> From: Brandon Ibach [mailto:brandon.ibach@xxxxxxxxxxxxxxxxxxx]
> Sent: den 20 april 2011 17:59
> To: xsl-list
> Subject: Re:  Copy-per-default
>
> Most (probably all, though I think we'd need more details on the latter
issue) of the behavior you're seeing can be explained by XSLT's built-in
templates.  See section 5.8 of the XSLT 1.0 specification [1], but in short,
they are:
>
> <xsl:template match="*|/">
>  <xsl:apply-templates/>
> </xsl:template>
>
> <xsl:template match="*|/" mode="m"><!-- One of these for each mode -->
>  <xsl:apply-templates mode="m"/>
> </xsl:template>
>
> <xsl:template match="text()|@*">
>  <xsl:value-of select="."/>
> </xsl:template>
>
> <xsl:template match="processing-instruction()|comment()"/>
>
> -Brandon :)
>
> [1] http://www.w3.org/TR/1999/REC-xslt-19991116#built-in-rule
>
> On Wed, Apr 20, 2011 at 11:24 AM, Fredrik Bengtsson
<Fredrik.Bengtsson@xxxxxxxxxxxx> wrote:
>> Hi,
>>
>> I am using FOP trunk to generate PDFs from DocBook documents on the command
line. Fop.bat is doing the XSL transformation, using whatever engine fop uses
(xalan?). I have written the XSLT entirely by myself, i.e. I am not using any
default DocBook transform or similar. The transform is small and under my
strict control.
>>
>> I am having the problem that the transform does not behave as expected in
two ways:
>> * Contents of nodes are being copied to the output as if there were
>> some kind of identity transform in effect by default even though I
>> have not written one, and
>> * Matches far down in the document cannot fetch data that existed
>> earlier in the document, as if select="/x" selected the x
>> post-transform instead of pre-transform
>>
>>
>> Imagine a document like this (ignoring namespaces etc for brevity):
>>
>> <book>
>>  <titleabbrev>THEDOC</titleabbrev>
>>  <chapter>
>>    <title>Ch. 2: The chapter</title>
>>    <titleabbrev>Ch. 2</titleabbrev>
>>  </chapter>
>> </book>
>>
>>
>> If I have the following transforms in place:
>>
>> <xsl:template match="/d:book">
>>  <!-- ignoring root, page-sequence etc for brevity -->
>>  <xsl:apply-templates />
>> </xsl:template>
>>
>> <xsl:template match="d:chapter">
>>  <xsl:apply-templates />
>> </xsl:template>
>>
>> <xsl:template match="d:chapter/d:title">
>>  <fo:block> ... ... </fo:block>
>> </xsl:template>
>>
>>
>> Then for some reason the titleabbrev appears in the output even though I
have not made any rule explicitly matching it. It is caught along with the
title inside the apply-templates under d:chapter. I thought that this would
not happen, unless I really added a matching template of some sort, for
example an identity transform.
>>
>>
>> I then just for fun tried to add the following template:
>>
>> <xsl:template match="*" />
>>
>>
>> That got rid of the offending titleabbrev, BUT it also had the effect of
breaking another template that special-cases the first chapter:
>>
>> <xsl:template match="d:chapter[1]">
>>  <xsl:variable name="abbr">
>>    <xsl:value-of select="/d:book/d:titleabbrev" />
>>  </xsl:variable>
>>  <!-- note: that selects a node that is higher up in the document -->
>>  <!-- now do something with $abbr -->
>> </xsl:template>
>>
>>
>> It seems that at that point, book/titleabbrev has already been transformed,
i.e. removed due to the catch-all template above, so $abbr is empty. That
strikes me as extremely strange; should the select not grab nodes from the
original unmodified document? If I remove the catch-all, $abbr is set properly
just as expected.
>>
>> This is really confusing! And again - I am not using a huge third-party
transform and modifying it, but rather using a really small, custom-written
and strict one under my control.
>>
>> /Fredrik

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

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