Subject: Re: XSL/CSS = XTL and XFO From: "Totolaricot" <totolaricot@xxxxxxxxxxx> Date: Thu, 10 Jun 1999 18:26:40 -0700 |
> Hi Didier, > > > Conclusion: > > If you want mass diffusion of your XML documents, it is preferable to use a > > XSLT engine located on the HTTP server (as a Servlet because most of them > > are Java based) and have this engine transform your XML documents into HTML > > to be rendered on as much browsers as possible. Client side transformation > > is still experimental except if your target audience is using Internet > > Explorer V5 and none are using other browsers like Mozilla, Opera and > > others. Thus, the choice is not as much dictated by technical virtues as it > > is dictated by common sense and document diffusion strategies. > > This server side XML + XSL -> HTML scheme has been working quite well at the > JavaLobby for 8-9 months now. Its an architecture that we have seen work and > that we will continue to evolve. While XSL has been a moving target, its > appears to be a worthy one and we intend to use more of it in the near > future. Same position here. I was in the position recently to advise one of my client as to which technologies he should use for the new release of their Archive Management software. The product allows their clients to manage archives, libraries, ... out-of-the-box, or design their own specific applications. Briefly summarized, their requirements were as follow: 1) the client interface should be available in a browser and as a standalone application (yes, there is a live after the browsers) 2) the customer should be able to customize the look of the documents in the standalone or browser environment, doing so only once 3) everything has to be 'non-programmer' targeted As some people have already stressed, the only truly interoperable technology available for influencing the presentation of web document (HTML page) without modifying the document is to use a separate CSS stylesheet. On the other hand, XSLT is a powerful and easy tool for transforming a document. We therefore decided to use XML/XSL/CSS. XML is used to tag the raw data as they are extracted from the back-end database (I have seen people store XML data into their databases, I personally think that at this point XML is better as a transport protocol. We'll see when more tools the like of Excelon are available). A Java Servile then does a Transformation into HTML. Because XSLT is a moving target, and today's actors may not be tomorrow's, the code on the Servile is written in such a way that changing the XSL/XML processor is one line in a configuration file. The resulting document is then displayed in the standalone or browser environment using a CSS stylesheet. With this combination, my client's customers have two level of customization available: 1) they can modify the CSS stylesheet. Some excellent tools are available for designing CSS stylesheets, and validating them for various browsers. This is for what he calls cosmetic changes. (he plans on bundling one with his product) 2) they can modify the XSLT stylesheet. There is no doubts in my mind that WYSIWYG XSL stylesheet editors will be available soon. That will allow the more involved customization of the final applications. This will be used in cases where the people would want to change the structure of the document. XSLT is simple enough that it can be mastered by non java/javascript/dom programmers. There has been enough feedback in that direction in this mailing-list. What made this solution work for us is primarily the fact that XSLT, although a part of XSL, can be considered a technology in its own right. I can only concur with Leventhal when he says: >The least that should be done is to separate XSL-FO and >XSL-transformations into two entirely separate initiatives. >I also advocate against approving a separate XSL-transformation >Recommendation as XSL-transformation does not serve any >of the purposes for which the W3C creates Recommendations. >Recommendations are there for key infrastructure which must >be interoperable. Multiple and redundant recommendations work >against, not for, interoperability. A document-to-document >transformation language like XSL has not been shown to be an >interoperability requirement and in any case is redundant with >already existing Recommendations. But unlike him, I do not think that the work on the separated proposals has to be caried outside of the W3C. According to the W3C itself, XSL is a language for expressing stylesheets (http://www.w3.org/Style/XSL/) But looking at the industry today, there seems to be a consensus that STYLESHEET means: the presentation attributes of a document (although VBA code can be embedded into a WinWord stylesheet, nobody would say that it is the amount of VBA code that defines the stylesheet). Applying this to XSL, a stylesheet should be defined independently from the processing declarations that it may or may not contain. Furthermore, If we are to draw on experience (HTML and CSS are prime examples), it is clear that keeping the two together will have two effects: 1) XSL will be even slower than CSS at becoming a standard. I mean an industry-wide 'reflex', not just a carefully crafted document seating on the W3c web site for people to read on long week-ends. 2) in the meantime, we will be swamped with XSL dialects, the same way sub HTMLs appeared in the past years. The only explanation I found for XSL (the FO aspect) and XSLT to co-existed under one single banner, was their XML nature, and their young age. Not every XML based language should be considered an extension of XSL, or we would pervert the eXtensibility of XSL. In the end, it appears that the name XSL has outlived its purpose. It was created to show that some people, realizing XML documents could need to be displayed, wnated to discuss possible ways of expressing the presentation semantic. The discussions happened, the brains worked ... Today, we have two newly born languages that are alive and well: eXtensibleFormatingObjects (the FO part of XSL) and eXtensibleTransformationLanguage (known today as XSLT). But unfortunately, they were born siamese twins, attached by the brains. In the eyes of the parents (the W3C), they are one single baby, but In the eyes of the family (the whole industry), they are really two different bodies. All it takes now is a daring surgeon to perform the physical NECESSARY separation. The separation will have several side effects: 1) XTL (XSLT) is a more mature proposal. Its simpler nature, compared to XFO, makes it approach-able by a larger crowed. Already there are several implementations available. Therefore, it will not take long before it becomes a real industry standard. I am sure that in that context, even the Mozilla team would include it in their work in no time. 2) The debate over XSL versus CSS will die for lack of opponents. XTL will impose itself as the de-facto standard for NON PROGRAMMING (yes, I do not consider designing an XTL stylesheet to be programming) document transformation. The DOM API will keep its position as a standard for dynamic transformations. 3)The same way there seams to be a consensus that CSS is too light-weight to satisfy the needs of printed documents, I think we would easily reach an agreement on the fact that XFO(XSL-FO) is too heavy-weight for disposable web documents. Incidentally, the fact that one of the godfathers of XSL-FO works at Adobe stresses how ambitious the goals are for XFO. 4) There will be another debate over XFO versus CSS, which should see the two co-exist, addressing two separate issues: CSS will mature as the standard for online formatting semantic whereas XFO, being much richer, will become the standard for rich, media neutral, formatting semantic. The emergence of converters from XFO to PDF, tex, ... already indicates that this is where we are going. On the other hand, not separating the two twins puts the two in danger, as they will perpetually feed-off one another. Please, let there be one surgeon to quickly separate them. Long live XTL and XFO. cheers, Laurent Michalkovic XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSL/CSS Tutorials, Michael Sick | Thread | Re: XSL/CSS = XTL and XFO, Totolaricot |
Re: how to display XML nodes having, G. Ken Holman | Date | Re: how to display XML nodes having, G. Ken Holman |
Month |