[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: XSL/CSS = XTL and XFO

---

---

> 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

---