Re: Inline scripting

[Guy_Murphy@xxxxxxxxxx]

Hi Chris.

I sense this is an emotive issue for you :)

Casting my mind back I beleive that the point was made that as querying
databases might be involved at some point, this
wasn't a good reason to include SQL in XSL (indeed quite valid)...
something like that, the main thrust of it was to illustrate that my
original extrapolation
was self evidently silly and facile I think, not sure.

My response, if I remember rightly was that actualy the post might have hit
on a relationship the responder hadn't seen, because
there is a relationship in the above example with XSL in that XSL does
indeed filter data as SQL might, to the point that the query
language for XML currently being drafted is modeled on XSL... somewhere in
that vague direction anyway :)

As to meeting your stated preference, rather than maybe acting on my own
preferences, I'll attempt to respond to what you feel to
be your more substantive point.

Yes making a language more expressive can make it less usable. As to this
being a fundamental principle of computer science
::shrug:: maybe, maybe not, I think I'd prefer to take your opinion on this
that your statement of fact. I would also suggest that it's possible
to assert that a language less expressive can also be less usable.

If as you suggest your assertion is a consistent fundamental principle, and
the expressiveness of a language was proportional to it's
usefulness then the most useful language would be the least expressive, but
there I go extrapolating again.

Now your point about an XSL document conforming to a DTD is very well made,
and not something I've given enough thought. Of course
implimmenting <xsl:eval> doesn't do away with applying a DTD to the XSL but
it does remove the the evaluation from the scope of the DTD,
but as you can't regulate, act on, or otherwise do anything with an
evaluation from the DTD I'm not sure of the relevance here. Essentialy
are we talking about an evaluation being contained within an attribute, or
being the content value of an element?

I'll have to ponder on this point further before myself making a
substatntive response.

As to the purity of the language enforcing somebodies notion of good coding
practice, my policy in this area is that I allow other developers
to to care of their own coding practice, and I resent the notion that
somebody is going to enforce good coding habits in developers by axing
features from a language.

My own feeling on the use of evaluation in general is that if it can be
part of the declarative language then all well and good, but what you will
be inclreasingly risking is turning XSL from a declaritive one to an
imperitive language. Also by forcing everything into the declaritive mould
you have to make damn sure you envisage all eventualities otherwise you end
up with a potentialy useless language.

It's been suggested that I go take a look at PROLOG so maybe I'll do just
that.

Actualy I feel as if I can sort of relax on this point, because I feel
absolutely sure that the MS XSL will include support for ECMAScript, so
it's likely
to go the way of FRAMEs in HTML, the W3C will try and pretend it doesn't
exist until it's silly.

Cheers
     Guy.





xsl-list@xxxxxxxxxxxxxxxx on 12/15/98 09:50:08 PM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  Inline scripting




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






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