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

Subject: Re: Fw: Is there a way to define groups of templates ?
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Sat, 26 Sep 1998 12:54:23 +0200
James Clark <jjc@xxxxxxxxxx> Wrote:

>Oren Ben-Kiki wrote:
>> Suppose that it was valid to say:
>>
>> <xsl:set name="my-variable" value="some-value">
>> ... and so on ...
>> 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.


Oops. Good point. I never considered this usage of XSL - too wrapped up in
my own problems, I guess.

OK, how about the following (slight) modification: Keep the 'xsl:set'
construct, allow "parameter(name)='value'" in qualifiers, but remove the
local/global scope modifier. Decree that a parameter _always_ reverts to its
original state once the rule setting it has finished processing. (I
intentially renamed 'variable' to 'parameter', since this is what it has
become).

I think this removes your objection wrt. "global state". It is just a
generic way to pass parameters "down the stack", as Paul has phrased it. You
could do your WYSIWYG editor. I could do my batch processing (using any of
the approaches Paul and I discussed, and many others). You could perform
rules incrementally, or in arbitrary order, or even in parallel, since they
can't theoretically effect each other.

How about it?

BTW, did anyone write an XSL processor which uses multiple threads to
concurrently process rules? There are interesting parallels here with
Dijkstra commited choice language, or Flat Concurrent Prolog, and simple
constraint languages. Should be interesting...

>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.

I beg to differ. I could trivially abandon XSL and XML and use another
mechanism for doing my file conversions. By using Java/JavaScript I could
even do so with browsers and be pretty portable. But I really rather not do
so.

The reason is that I believe (hope?) that XML/XSL would bring a measure of
sanity to the structured file format chaos we have today. When (if?) this
will happen, XML/XSL support would be very widespread - built into browsers,
operating systems, indexing tools, and so on. I want my application to be
part of that - even if it is "batch processing" and "could be done in perl".

>  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 very seriously doubt that XSL would be hand-written by graphic artists.
HTML (without scripting) is by far simpler then XSL. Personally I write HTML
using 'vi', but graphic artists use WYSIWYG HTML editors/generators. This
does not mean HTML is "inaccessible" to them. XSL, being more complex (if
statements, pattern matching, macros...) would go that way much faster then
HTML did.

We shouldn't feel bad about this. The "lets make it so simple anyone can use
it" approach has never worked in the past. It never will. The best we can
achieve is "lets make it simple enough anyone can use it for simple things".
XML, HTML and XSL do that pretty well.

Share & Enjoy,

    Oren Ben-Kiki


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


Current Thread