Inline scripting

[Paul Prescod <paul@xxxxxxxxxxx>]

Guy_Murphy@xxxxxxxxxx wrote:
> 
> Hi.
> 
> XSL may not incorporate SQL, but XQL is modeled on XSL to the point W3C
> states the will be cross fertilisation between the two. So I'm not sure
> that you example does other than prove value in extrapolating an arguement
> to help examin it's main factors.

What does the relationship between XQL and XSL have to do with *SQL*???

I would prefer if you would respond to my substantive point that making
languages MORE expressive can actually make them LESS rigorous and usable.
This is one of the most fundamental principles of computer science. Less
can be more. Let me refer you (again) to:

http://www.w3.org/People/Connolly/drafts/html-essay

--

Consider Chris Maden's simple example. I have a document with 300
javascript scripts in it. I delete the first one in a WYSIWYG editor. Now
I scroll to the bottom. The editing tool must run every one of those 300
scripts because any of them could affect something that changes the stuff
at the bottom. Furthermore, if any of them has a bug that causes an
infinite loop, I can't even display the document. 

If the script is in a separate file, the WYSIWYG editor could either
ignore it or report that there is something wrong with it and say that it
is going to use only the XSL stylesheet and not the script. But you can't
do that if the script is inline because you have no idea if you are
interpreting the other rules correctly.

Now this is just a blatantly obvious example. There are also hundreds of
more subtle problems along a similar vein. For instance, wouldn't it be
nice to be able to write an XSL transformation and know that the result of
its application is a valid document according to some DTD or schema? That
MAY be possible if we do NOT allow scripting, but it will certainly NOT be
possible if we do.

There are also many performance optimizations that can be accomplished
under the current system that are not possible with global variables and
scripting.

Furthermore, allowing people to embed Javascript will encourage them to do
so. This means that:

 a) they may never learn good habits that improve reliability and
performance.

 b) standardizers will be less likely to implement new features in the
declarative syntax because we will be able to point to the way to do it in
Javascript.

If the break between scripting and XSL is clean, then we are motivated to
carefully move things into the declarative syntax to reduce the need for
external scripts. If it is all in one spec. we are likely to say: "well,
as long as they can do it in scripts, why bother making a declarative
syntax for it."

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

"Sports utility vehicles are gated communities on wheels" - Anon


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