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: Attributes, modes and templates


>>>>> "AL" == Alex Lancaster <alex@santafe.edu> writes:

AL> In DSSSL, with the above fragment, if the element is listed in the
AL> `mode' then you get that behaviour, if it's not then you always
AL> default to the rule in the imported/included stylesheet.

>>>>> "WP" == Wendell Piez <wapiez@mulberrytech.com> writes:

WP> (But you kick back into the mode as soon as you have a DSSSL
WP> construction rule in the mode again, don't you.)

Wendell,

Yes, exactly!  (I should have ended my last sentence by saying... "and
then, if after going back to the default rule, another element is
encountered that *is* defined in my mode, I process *that*
accordingly, weaving in and out of the mode appropriately")

AL> In XSL it appears that that is not the semantics of processing the
AL> modes.

WP> That is correct, modes do not operate the same way in XSL. See 5.7
WP> in the spec, where it says "if an xsl:apply-templates element does
WP> not have a mode attribute, then it applies only to those template
WP> rules that do not have a mode attribute." So XSL templates are not
WP> quite as "fluid" as DSSSL element construction rules. 

That's exactly the problem.  When I first saw `mode's in XSL, I
thought: oh goody, I can pretty much mechanically translate my DSSSL
stylesheets, just by changing the syntax.  How wrong I was.  It seemed
entirely natural that the stylesheets would weave in and out of modes
appropriately (otherwise you're stuck having to reimplement the
match rules for everything in your mode).

WP> Your trouble is here: unless you change the templates in the
WP> imported stylesheet, there's no way to get back into the mode once
WP> you've exited it.

WP> I can envision ways of engineering the behavior you want (passing
WP> parameters down through the processing, that kind of thing), but
WP> nothing that respects the requirement to use the imported
WP> templates unchanged.

Yep, it really seems like a crazy limitation on XSL.  I can imagine
it's not an issue that arises much if you are writing XSL stylesheets
from scratch (which judging from posts to this list, seems the
majority of users of XSL).  However, if you want to do any kind of
customization of modular stylesheets (such as Norm Walsh's XSL for
DocBook) beyond the blindly trivial, it's a must.

Of course, any workarounds in XSL to approximate the DSSSL behaviour
(a la the passing parameters suggestion above), will be greatly
appreciated.  I'll also cogitate further and see if I can come up with
something independently.  Obviously a solution can't be more
complicated than reimplementing the imported elements in the mode,
otherwise I'm not buying any simplification.

WP> I wonder if any DSSSL wizards on this list can think of an elegant
WP> way to do this in XSL. Or maybe someone who knows no DSSSL and
WP> thus doesn't expect modes to work the way they do there. Bother.

Bother, indeed... To be honest: I'm totally staggered that this isn't
a FAQ, since this is the kind of thing I do with my DSSSL stylesheets
all the time (it seems almost as natural as breathing! ;-)).  In fact,
I pretty much rely on it, and I'm sure that there must be other
DSSSL-ites migrating to XSL who have stubbed their toe on this very
issue.

Yours in XSL despondency,

Alex
-- 
Alex Lancaster * alex@santafe.edu * www.santafe.edu/~alex * 505 984-8800 x242
Santa Fe Institute (www.santafe.edu) & Swarm Development Group (www.swarm.org)


 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]