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