Re: Fw: Is there a way to define groups of templates ?

James Clark wrote:

> Oren Ben-Kiki wrote:
> > Suppose that it was valid to say:
> >
> > <xsl:set name="my-variable" value="some-value">
> >
> > And later specify, in any pattern, "variable(my-variable)='some-value'".
> > This would be legal in qualifiers, and would behave just like
> > "attribute(name)='value'" except it would access the global variables table
> > instead of the element's attributes.
> >
> > We'd also like 'xsl:set' to have an optional "global" modifier, which
> > supresses reseting the variable to its original state once the current rule
> > is done. The ability _not_ to restore the variable at the end of the rule
> > gives raise to interesting possibilities...
>
> > Do you see any disadvantage to this idea?
>
> XSL isn't just intended for batch processing.  For example, XSL should
> allow you to write a WYSIWYG XML editor that uses XSL to display the
> XML.  It should be possible to construct the formatting object tree
> incrementally.  Any sort of global state makes this very hard to do.
>
> Also remember that the intended audience for XSL isn't people like you
> (or I suspect most of the people on this list).  I would guess most
> people on this list are comfortable writing a perl script or maybe a bit
> javascript.  If XSL is to succeed, it must be accessible to people who
> don't have those kinds of skills (eg graphic artists).  Although setting
> and accessing variables is easy and intuitive for programmers or people
> with programming experience, it isn't so good for non-programmers.

I think this all goes down to the big argument of scripting solutions vs.
parameter-driven solutions.  The current draft fortunately dropped ECMAScript as
I feel it cluttered XSL's intentions.  The current XSL draft is more of a
parameter-driven solution now (I applaud this) than the previous draft.

For non-programmers and programmers alike I feel parameter-driven solutions are
much simpler for people to grasp and much more extensible in just about every
way.  You just need to know the parameters rather than how to program and the
syntax associated with it.  This I suppose is a bit of a value judgement since I
generally have a disdain to scripting in the first place as I find them usually
employed as a beat the project with a hammer approach to getting things done.  I
am not saying that PERL and other scripting languages are generally useless, I am
just saying that turning XSL into a real bonified scripting language would be a
serious mistake.

On a sidenote, my initial impressions of the current XSL draft I did not like
much, but after implementing an XSL Processor for a particular client, I have
since changed my impressions considerably.  The most suprising thing I have found
is that the XSL Processor's performance is much better than what I had originally
thought possible.  For my current implementation building the DOM tree and the
Stylesheet tree takes about 80% of the processing time.  Doing all of the pattern
matching and then spitting out the output takes about 20% of the time.  Of course
this will vary mostly on the size of the source tree and the complexity of the
stylesheet, but I had originally thought that things would be the other way
around.  I guess this for me is an affirmation that under the current XSL spec it
is possible to write XSL Processors that are suitable for on-the-fly dynamic
processing of content to something like HTML.  My original speculation was that
there would be some serious performance problems when implementing XSL
Processors.

Tyler


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