Re: Language is not markup and markup is not language.

Subject: Re: Language is not markup and markup is not language.
From: Guy_Murphy@xxxxxxxxxx
Date: Mon, 10 May 1999 11:08:40 +0100
Hi.

I believe that I covered the advantages XSL has over "normal" scripting
languages, in that it has all the benefits of beign queried, pointed into,
split easily etc. I don't believe this to be so for ECMAScript. I don't
belive that you can easily use XPointer to point into ECMAScript.

You ask for an example of the "etc etc"...

I have a large body of XSL... the spec changes, and my XSL stylesheets are
no longer compliant with current implimentation.... I transform the
existing XSL stylsheets so they now conform. Or maybe the spec hasn't
changed, but I need to support a non-standard platform.... likewise I can
transform to compliance with that platform.

Or maybe I have fat feed of data, each document/dataset in which comes with
a DCD/DDML or whatever XML Schema [marked up in XML] with support for a
rich datatype used, but no stylesheets specified. I can transform the
Schema into a default XSL stylesheet for that document. Not pretty, but
renderable in a reasonable fashion. Yes I could transform into TCL, but
generating script in such a fashion is *not* easy (having generated
complicated JScript from ASP I certainly found it difficult to debug).

Or maybe we get some sort accessibility addition to XSL, either in the way
of mapping, or richer FOs, or maybe the W3C doesn't get it through for XSL
1.0, so I want to employ my own mechanism for describing mapping, and
support form aural presentation object on the client-side, I can transform
such an XSL stylesheet into a diffirent stylesheet with aural POs.

Or when IE6 comes out with say XFO support, I might want to transform
existing IE5 XSL stylesheet used on our intranet app to make use of XFOs
rather than HTML.

I respect the fact that others might want a diffirent XSL. My own point of
view is that we already have CSS and an XML DOM. If one wants a scripted
solution, you already have one. Personally, I have used ASP an awful lot,
and by far and away find XSL far more suitable to the task. Being more
scalable, easier to test, debug, and change. With significantly greater
reuse potential than script (in that it can be transformed).

XSL isn't just for styling Web pages. It's also for large Web applications,
and machine processing. Yes most people doing a persoanl or small business
site will use CSS, with some script. Good, XSL was never intended to
replace CSS, nor was it intended to address the same problems.

As for the general approach to XSL syntax... again this is largely down to
my own personal taste, but I find the template approach the best method, in
that it neatly deals with recursion, in a fashion that most users wont
really think about the recursive nature of the processing they're
describing. Personally I think I'd have far more debugginh to do with an
scripted application where I was having to handle myself the degree of
recursion in most XSL stylesheets.

And the pattern matching syntax, I think is just great. The suitablity of
it for specifying XML patterns cna be supported by how quickly it got
snatched up as XQL.

This is all largely my own personal taste being expressed here. Not claims
of "what's right". The only thing I would repeat is that, we already have
XML DOM, script and CSS. XSL is for the stuff that's a *real* pain with DOM
script and CSS.

Cheers

     Guy.





xsl-list@xxxxxxxxxxxxxxxx on 05/07/99 07:15:08 PM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  Re: Language is not markup and markup is not language.




[SNIP]
Ok, what does "xslt scripting" have over a general purpose scripting
language like pearl or tcl?
>Didier is actualy working on a development pretty much exactly as you
>outline called XStyles, that you might find interesting. And has
advantages
>of leaveraging previous experience, choice of scripting implimentation,
and
>well, how can I say?... more directness.
Is there a URL for this?
>While I think it a *very* worthwhile and useful effort, I don't see it as
>competing necessarily with XSL as the advantage of XSL over a scripted
>implimnetation is that the very fact that XSL is XML means that it can be
>treated as data, transformed, pointed into, queried, split into sub-trees
>etc etc.
Hmm... yet javascript, pearl, tcl and lisp can also be treated as data,
transformed, and pointed into. I am not at all clear on the utility of
querying a script element and I would argue that a sub-tree of a script is
semantically meaningless. What other etc. etc. did you have in mind?
>It's for these reasons that XSL is in the form of XML, and that
>the general drive is toward all XML related technologies being described
in
>XML.
Well, one point of my post, perhaps not clearly stated, is that mark up
notations are great for marking up data, but not so great for programming
language representation.
>As far as the inclusion of a script tag in XSL is concerned, I personally
>believe that it should be there (and regardless of Rec will be there),
>although I do understand the concerns that some have over this.
I agree (of course :-) )! Why not bow to the inevitable and put the script
tag in the reccommendation now? At the very least, it would make Microsoft
go to the trouble of making VB both unicode compliant and force them to
port it to Unix/Linux - and we could continue to ignore it!
>Cheers
>
>     Guy.
>
I received a private post from someone asserting that xslt's language seems
to have it's roots in "tree transformation languages". Seems to me that
most general purpose languages are pretty adept at tree manipulations - and
a host of other useful things as well.
Dave LeBlanc

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






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


Current Thread