Re: Formatting elements

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() &gt; 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