Re: [xsl] something I'd really like in XSLT

["bryan rasmussen" <rasmussen.bryan@xxxxxxxxx>]

No, I'm not suggesting a way of doing something that I already know
how to do (actually maybe I am, just in a way that is quicker for me
to get particular types of labor intensive work done)

And yes, I would probably not need (okay need is probably too strong a
word, would find it somewhat useful when presented with particular
types of problems) to do any of this if I had three stylesheets and
especially if they were all written and maintained by me.

If on the other hand I have lots and lots of stylesheets, some
auto-generated, some authored by others etc. then I might need some of
this.

At any rate I am not arguing that what I had was the way the problem
should be solved, I was arguing that it was a poor way of solving a
problem (because of complexity) and therefore would like other ways to
solve it.

I guess aside from this it would be useful if one knew where the lower
priority was. In a complicated enough system I might say okay I want
to let the lower level override me unless it is in the stylesheet Z or
it has an import precedence lower than -2.

Why would I do this instead of just throwing out Stylesheet Z, because
Stylesheet Z has things that are useful when Stylesheet Z is run in
stylesheet X. Also StyleSheet Z is really great when it is run by
itself.

Let us suppose I have a system of media generation with a stylesheet
for presenting the information in Schematron.

This stylesheet was written by Tom who has a really good understanding
of Schematron and came up with a bunch of good templates for taking
apart the rules of schematron and presenting them usefully to the end
user.

Unfortunately Tom is no longer with us, having run off to spain to
pursue his dream of becoming a Matador.

However I am using Tom's stuff in four other stylesheets and it is
great, so no editing Tom's stylesheet.

I also wrote a stylesheet for doing visualisation of Schematron that
is floating around the system and being used in several presentations.
It is not as good as Tom's but it is good in some specific ways for
simpler presentation.
Gary needs to import both Tom's and my stylesheets into several other
stylesheets such as a stylesheet for doing
GML validation analysis. He wants to use Tom's stuff for specific
types of analysis but wants to reuse most of mine for other types of
visualization (maybe because a lot of Tom's is table based I don't
know

Now it's true by reading through all the stylesheets and figuring out
what does what, then he can go and make a stylesheet with the correct
import order, and then write the 20+ templates he needs to handle
integrating Toms and my stuff wisely, this won't take him too long to
do because he knows sort of the structure of these stylesheets anyway.
It is sort of difficult with Tom because Tom is gone and never
documents but he can do it, unfortunately the delivery of his
stylesheet needs to be in 4 days. This is cutting it sort of close. He
can't produce everything in the four days starting from scratch, but
he can't produce everything in four days going through the stylesheets
either (maybe but it is close). But he can produce the stylesheets in
four days if he had the kind of reflective capability that he could
analyse where in an import order the next match was coming, the name
of the stylesheet maybe,  if the match was more expressive than the
current match, and so forth.

All things that can be done by analytical tools externally (if you
have any that can do it, these tools are probably just theoretical at
the moment) so probably what Gary should have are better tools.




Cheers,
Bryan Rasmussen

On 1/23/07, David Carlisle <davidc@xxxxxxxxx> wrote:
> > now this is of course not a useful example but we can see how the
> > first example template matches normal priority operation (but the
> > running of the template is not affected by the priority rules of the
> > template, basically the execution of the template is now affected by
> > the priority of how one matches the same element in the ismatched
> > mode) with the exception that I can switch execution dependent on if
> > there is an import that matches. I can of course do this by running
> > xsl:apply-imports and testing if there is any content of my variable
> > but it seems somewhat fragile to say the least.
>
> I didn't follow all the logic here but it seems to be very complicated,
> and attempting to duplicate much of the matching semantics within xslt.
>
> If the requirement is "if foo.xsl and bar.xsl have templates that match
> this node do what they specify else do ...)
>
> Then you can do that without any explict xsl:if testing, just have a top
> level stylesheet that says
>
> <xsl:import href="default.xsl"/>
> <xsl:import href="foo.xsl"/>
> <xsl:import href="bar.xsl"/>
>
>
> where default.xsl has a template that matches the node and does ... it will
> have lowest import precedence so only be invoked if no other template
> matches.
>
> David