Subject: Re: Formatting elements From: Paul Tchistopolskii <paul@xxxxxxx> Date: Wed, 04 Oct 2000 20:38:41 -0700 |
Jeni, > >I'll first give XSLScript notation and then will be the XSL code > >( generated, as usual ). I think this should illustrate the > >real value of terseness. > > Thanks for giving us a taste of XSLScript - it's really interesting to see > it in action. However, your solution doesn't cope 'properly' with: > > <document> > <item name='title'><text>Title field</text></item> > <item name='bullet1'><text>some text for item 1</text></item> > <item name='bullet2'><text>some text for item 2</text></item> > <item name='bullet3'><text/></item> > <item name='bullet4'><text/></item> > <item name='bullet5'><text/></item> > <item name='bullet6'><text/></item> > <item name='bullet1'><text>some text for item 1</text></item> > <item name='bullet2'><text>some text for item 2</text></item> > <item name='bullet3'><text/></item> > <item name='bullet4'><text/></item> > </document> > > as it creates only a single bulletlist in this case whereas I think it > should create two. You are right, I thought it should create one. I just looked at your sample and the desired output and then quickly wrote the transformation, tested it on the sample - and posted it. Sorry. With 'pure functional way' this is not a problem to change the transformation to accept more conditions / requirments. 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 ;-) Let's just rewrite first-non-bul , so that it will take into account the <number> in bullet<number> and any other type<number>. This means the 'breaking' should happen not only if type1 != type2, but also if we have type<num1> type<num2> and <num2> is *less* than <num1>, right ? So first-non-bul becomes something like : X:template first-breaking-pos ( list, count ) { <% X:if "$list" { <% X:var type="string($list[1]/@name)" %> <% X:var next-type="string($list[2]/@name)" %> <% X:var should-break = { <% !compare-two-types-taking-digits-into-account( a="$type", b="$next-type" ) %> } %> <% X:if "not ($should-break)" { <% !first-non-bul( list="$list[ position() > 1 ]", count="$count + 1" ) %> } else { <% {$count} %> } %> } else { <% {$count} %> } %> } New codition appeared but changes are localized and the entire structure of the stylesheet has not changed at all. I doubt similiar mutations are that easy with key()-based solutions. > Out of interest, could you give another example that deals with this as > well? I only ask because it is relatively easy to develop a relatively > terse Muenchian solution that deals with only 'bullet' cases, and I'm not > particularly happy with the solution I gave (which was pretty ugly mainly > because of the hoops I had to jump through to account for this > generalisation), and would like to see it improved on, particularly if > XSLScript can do so. Don't worry if you don't have time. 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>. 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? ;-) <rant> Even it could be interesting to invent tricky SQL queries to work with bad SQL schema ( I'm doing this every day. In the US it is common to build relatively big systems on the SQL schema designed by some student on the weekend. It is really amazing - I have not seen such practices in Europe. This results in a huge vaste of resources, but gives a lot of fun writing SQL code for such a systems </rant>. I think it is always better to tune the schema. The same is true for XML, I think. One more thing. 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. Why? Because flat->hierarchy is done with 'get the flat list ordered by something' - 'break at some point' 'call yourself with the rest of the list'. This ( core XSL ) pattern invented when rewriting Sebastian's test6 remains rock solid. It already allowed me to solve at least 3 transformations which were regarded 'complex' - and I did that with almost no mental effort ( the effort is to invent the pattern, not to apply it ). When I now see something 'complex' I'm thinking only how can I produce the sorted list ;-) The rest is already solved. ;-) Sure sorted list equals to key() in some sense, but sorted list is easeir for understanding ;-) OK, but use this ( general ) pattern, some custom functions have to be introduced for checking different conditions of breaking. Here comes the problem of XSLT verbosity - it is hard to write functions in XSLT. Here comes a solution - XSLScript ;-) My point is that with XSLScript + pipes I can write 'complex' transformations in minutes not spending too much time on thinking. A small number of patterns + handy functions is all I need. So in fact I'm not talking about the verbosity of the XSLT stylesheet. I'm talking about ease of writing complex and mutable ( because people like to change the dataflows ) transformations. Sofar I think that functional view + pipes gives better results when ease of writing / reading is a priority. I'm sure that you, Sebastian, Steve, David, Michael, James and other smart fellows can write some masterpieces of XSLT, combining key() / modes e t.c. Maybe { <% !compare-two-types-taking-digits-into-account( a="$type", b="$next-type" ) %> } %> could be written in one Xpath expression. I dunno. I never tried writing a brilliant perl one-liner, because I know I just can not compente with some other people whom I know, who can write those one-liners. I prefer writing something dumb. Robust, efficient and maintainable. People are different. Rgds.Paul. PS. With next version of XSLScript it should become more clear. I think I finally found the elegant way to improve the current syntax. That took 2 months. Just to understand how could it be improved - not to implement. It is very hard to produce a 'really good' syntax not testing the language and I think importantce of syntax is underestimated in XSLT. That was my point, not that your solution is 'bad' or my is 'better'. To me my is better only because I was able to write it in minutes. Honestly, I'm sorry, I have not looked into your solution deeply. It was hard for me to understand what is the algoritm. I just cheked for the recursion and became sure that your algoritm is different from mine ;-) XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Formatting elements, Jeni Tennison | Thread | Re: Formatting elements, Jeni Tennison |
RE: XSL attribute expression, Don Hill | Date | indent XML doc based on spaces?, Joshua Allen |
Month |