Subject: Re: XSL Requirements (was: Microsoft extensions to XSL) From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Mon, 16 Nov 1998 12:34:22 +0200 |
Ed Nixon <ed.nixon@xxxxxxxxxxxxxxxxx> wrote: >[Obk] ... I think we have a basic disagreement between people who use merely >the first part of the intent - XSL as a transformational language - and >people who also care about the other part, the formatting semantics. > >[edN] I wonder how much of this split will still exist in 6 + months when the >browser bowsers manage to get something working with respect to XML and CSS, >XSL, and even DSL? (I've mentioned the InDelv alpha/beta code before as and >example of alternatives -- pretty good support for basic formatting objects a >la current draft, not so strong but still respectable on the template/select >side.) My bet is that the formatting part of XSL would just wither away. CSS seems, at the moment, to have much more momentum as being "the" style sheet language. On the other hand, XSL seems to have a fair momentum as being "the" transformation language to use... Of course, my crystal ball doesn't have a warranty :-) >[Obk] The first group would like a transformational language which is strong >enough to convert XML into whatever target language they need. Being >accessible to the end user is a minor concern. > >[edN] We've just seen some posts pointing to all sorts of alternatives for >doing this. If the argument is that it should be done client side as opposed to >server side, I wonder if this is realistic at this point in the evolution of >things? It is. There are great benefits in doing this - reducing bandwith, increasing application responsiveness, reducing server loads... And clients today are Pentium II machines with cycles to spare. It makes perfect sense to go this way. In fact, my company was going to do client-side transformations regardless of XSL; we chose XSL over rolling our own transformation engine so as to better integrate in the evolving Internet environment. >[Obk] The second group would like a flexible style sheet language for HTML graphic >designers. Being accessible to such designers is a major concern. > >[edN] I wonder how much of this pent-up and frustrated demand can be placed at >the doorstep of the rather half-hearted, inconsistent and downright buggy >implementations of CSS that we have to contend with? Exactly. But I expect that the next generation CSS implementation would be much better, by then people would be used to CSS, and the XSL alternative would be less relevant. >[Obk] Is there any chance of splitting the XSL draft into two - say, XTL >(eXtendible Transformational Language) and XFL (eXtendible Formatting >Language)? > >[edN] In effect, this has been done (if not formally announced), I think. >There was some back and forth a month or so ago about focusing on the >transformation side in the short term (whatever that means) and leaving the >formatting side to later in the process. Realistically, what tools exist do >this and not much of anything else -- XP/XT, Koala XSL > >I wonder if the division isn't rather neatly captured already? On the one hand, >in the notion of the template matching and relatively straight forward output >mechanism, i.e., new tag names, additional text, process-children, etc.; on the >other, with the 'fo' mechanism, i.e., display space management, graphics, text >formatting, etc. > >Are you suggesting that there should be two separate and free standing specs? Yes, exactly. I think the formatting semantics should be just another XML language. It could compete with CSS on an equal basis for being the stylesheet language of choice. This should not effect the use of XSL as a transformational language. >Maybe I'm already corrupted but I like the notion of being able to select, >change/re-order, and show content all in the same place. Selecting and re-ordering are transformational processes. As for showing the content, by generating XML <fo:*> formatting tags - I'd like to see a design criteria which defines what is the scope of the <fo:*> name space. In particular, given some issue regarding display of some entities, should it be in <fo:*> or does it warrant a separate XML language? Keep in mind we have quite a few display related XML languages in the works - for 2D/3D graphics; for mathematical formulas; not to mention we have the HTML "display" language. >What I'm not so convinced is necessary is the ability to run a bunch of >procedural code as well -- this was the thrust of my initial response to the >thread. As Didier PH Martin (mailto:martind@xxxxxxxxxxxxx) correctly pointed out, a pattern matching language is never sufficient by itself to do general structural transformations. He's also correct in that it would have been interesting to start with a procedural language (say, JavaScript) and add pattern matching facilities to it, instead of starting with a pattern matching language and adding procedural hooks to it. The benefits of XSL's approach is that the simple things are less intimidating then they would have been in a souped-up JavaScript approach. This may explain the level of interest that XSL has generated. But to keep and build on this level of initial interest, XSL must provide the ability to do the more complex stuff as well. There are several features which related to this, not only scripting language integration - processing modes is a good example, and local constants/parameters, and so on. Share & Enjoy, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: XSL Requirements (was: Microsof, Ed Nixon | Thread | Re: XSL Requirements (was: Microsof, Daniel Glazman |
Re: RE: More fun with MSIE, Steve Muench | Date | Doubt regarding content model of <x, Amit Rekhi |
Month |