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: Fri, 7 May 1999 10:41:47 +0100
Hi Dave.

Your arguement is interesting, and personaly I would say not without
merits, in that what you suggest might indeed be a good thing, but not
really in place of XSLT.

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.

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

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.

Cheers

     Guy.





xsl-list@xxxxxxxxxxxxxxxx on 05/07/99 08:57:07 AM

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




I have noticed that the introduction of procedural language as markup in
XSL has been more or less a non-event. I do not understand why XML (which,
contraty to it's name, is not a language per se), benefits from having
percedural language masquerading as markup? It seems analgous to putting
style information into an XML tag set instead of focusing on what XML is
intended for: recording information about the structure of data.
To make it short, sweet and to the point, adding a bunch of decorations in
the form of <xsl:blather>....</xsl:blather> instead of a nice <script
language = "some conformant language"> script content </script> with a well
defined set of requirements of what "some conformant language" needs to
provide (such as Unicode, multi-platform availability, a standard
transformation library, etc.) seems pointless. (Unless of course, there's a
behind the scenes political battle raging along the lines of "if it's not
going to be MY language, it sure as hell isn't going to be YOUR language".
This may be the only saving grace of this whole xsl:statement fiasco, it's
not going to be Basic!)
This does not even begin to address the abandonment of the man years and
even man centuries of work that have gone into developing languages such as
pearl, tcl, javascript and yes, even lisp and basic, that either are or
could be made conformant to a reasonable set of requirements instead of
another round of learning yet another language (xsl procedural markup) and
it's idiosyncracies. It seems to me that the time of the XSL comittee could
be better spent developing a good STYLE and/or TRANSFORMATION notation
rather then diluting the effort with procedural language elements.
Has the notion of KISS been lost in the interest of some abstract elegance
that appears to perform no useful purpose?
One may indeed be able to push the elephant through the mouse hole, but the
resulting white (loss of blood) elephant may end up on the rubbish heap due
to lack of use, interest, or convenient utility.
Excuse me while I seek a fall out shelter now.
Dave LeBlanc
P.S. Those who would argue that XML is a language might care to look up the
notion of Turing Completeness among other things that diferentiate a
programming language from a data structuring notation.
P.P.S Of course, if xslt does fail as a standard, it does leave the door
open for some other defacto standard to take it's place - like partial xslt
with a <script> tag for instance. :-) Remember, it's (going to be) a
reccommendation and not a law of the universe - micronitexploderscrape not
withstanding.

 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