Re: Formatting elements

Subject: Re: Formatting elements
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Mon, 09 Oct 2000 14:34:23 +0100
Paul,

>That's what I'm trying to show. I'm trying to show that verbosity
>of call-template + verbosity of missing else sometimes forces
>people to find some not-obvious ways for doing things that are
>in fact really simple. It is just because it is a pain to write
>call-template in XSL ;-)

Amen.  I recently rewrote some stylesheets in a way that was supposed to
make them more extensible and maintainable, but ended up making them look
incredibly verbose and complex because of all the xsl:with-params all over
the place.  xsl:call-template isn't the only problem: it's
xsl:apply-templates as well.

>I do have some time, but I don't understand, for example,
>what is your requirement for rendering menu<number>.
>I mean rendering to <menulist> is not the same as rendering
>to <menu>.

I was just trying to think of another type of list that you might use, and
'menu' is all that I could come up with.  The point is that the code
shouldn't be restricted to 'bullet' lists, not in the semantics of what's
actually used.

>Also I don't want to spend too much time
>working on ... suspicious ... data structures.  I mean
>it should be at least name="bullet" n="1".  What about
>pipe of 2 transformations, when the first-one is cleaning
>the mess in the schema, separating numbers from content? ;-)
>OK, if there will be pipe of 2 transformations, maybe something
>else could be done on the first step? ;-)

I think it's a very interesting issue how much XML structures *do* have an
effect on what is possible/easy/difficult/impossible to do using XSLT.  I
used to think that as long as the information was there, then it would be
possible to do anything with it in XSLT, but in fact it is very possible to
come up with schemas that create work for the XSLT author by increasing the
amount of string manipulation that's required.  XSLT1.1 will help this
somewhat by allowing use of result tree fragments to pre-parse information.
 Something like saxon:function would also be very useful in this regard.
But it would be good if we could come up with a set of guidelines for
schema writers to help them produce schemas that are easy to use XSLT on.

>You may introduce some more complex conditions,
>but the pattern I've used in my solution will *not*
>change almost no matter what particular requirments
>could be introduced.

Part of the reason I was interested in seeing your solution to the extended
problem (aside from seeing more of XSLScript) was that the pattern that
I've used for flat to hierarchy transformations in the past (i.e. group in
a key on breaking point, apply templates to first in group, process group)
had to change because of the complex conditions - it's certainly
interesting that it doesn't with yours.  I don't like the solution I came
up with and I'd like to learn a better approach.  I'm be very grateful if
you could post the (generated) XSLT from the completed solution (with the
new first-breaking-pos template) so that I can see more clearly how to
apply it in future cases where I'm faced with this problem.

Thanks very much,

Jeni

Jeni Tennison
http://www.jenitennison.com/


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


Current Thread