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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Fw: Language is not markup and mark, Larry Fitzpatrick | Thread | RE: Language is not markup and mark, Kay Michael |
Re: Part A - Generic parse.allXML f, David Carlisle | Date | Re: Language is not markup and mark, Paul Prescod |
Month |