RE: Venting

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

HI Dave,

<YourComment>
Ok, it seems apparent that the transformation component can be independent
of the stylistic component of XSL. Is the converse true? Can you go from an
XML document or DOM representation directly to the FO output without doing
transformation? If not, then maybe transformation and style do need to be
one - perhaps with an "FO implementation can be optional but must be based
on the transformations in the XSL REC".
</YourComment>

<Reply>
Yes you can. In fact, you can use CSS to render a XML document. In this
case, you associate a style property set to each element (or class if you
wich). It is even possible to create a CSS engine that can output the XML
document with a CSS style sheet in PDF format or whatever you can imagine.
If you take for example, the actual Microsoft implementation, it can render
a XML document with a CSS and so will do the next Mozilla release. Thus, if
transformation is separated from formatting in the actual XSL specs, it
won't leave a big vacuum, CSS could be use to that usage. However, on short
term XSL could be used to transform XML into HTML and be mostly server side.
This would, serves well the actual market. The other advantage from a
commercial point of view is that XML could be introduced sooner without
having even the support of big guys implementing XSL on their client. Let's
imagine the following probable scenarios:

a) Microsoft releases a version 5.0 before this summer. It will include a
CSS1 implementation and maybe a XSL implementation but if that is the case
most surely the transformation part and probably more used in IIS (Don't
forget that the whole browser is in fact a set of components. The XSL
intepreter is a component. Its output is HTML and can be used in IIS). The
Microsoft Browser market (i.e. people having the Microsoft browser) could be
renewed in about 1 to 2 years. This means that in two years about 80% to 90%
of the market will have a the version 5.0.
b) Mozilla is released this year too. It includes CSS1 also. The Mozilla
market will take too about two year to attain 90% market penetration (i.e 2
years to have 90% of the market have Mozilla 5.0). It probaly won't include
XSL because there is no actual work in progress for XSL. There is however
work in progress for CSS (test stage and I should say tests are quite
comforting)

c) XSL is split into a transformation part and a formatting object part.
Several XSL implementations hit the market this year and in majoriy server
side. Mostly will be used for XML to HTML transformation and 100% of the
browser market could be reached depending of the HTML version level
supported (with 3.2 you have near 100%, with 4.0 not yet). Because you have
XSL implementations available the XML movement is accelerated mostly because
it doesn't depend on big guys *you know, why rush they own the market! All
small companies introducing XSL server side processor count a lot on the XML
wave where all the cards are not played yet and the market not yet mature
and in a certain way not frozen with the same players. End result of the
scenario, XML reach the market beach this year, not just announcement of new
XML based languages but site running with it ( a bit like the Java lobby
site is doing today). This could bring a wave of migration from SGML
documents to XML (the step is not so big) Some may also introduce front end
to database that produce XML and then pass it through the server based XSL
servers and get it delivered to the actual market as HTML. This could even
force again the big guys to have a SQL query return a XML document instead
of a proprietary format like it is today. and so on.

<Conclusion>
You can introduce "XSL transformation" only and could encourage mostly the
server side server market. 5.0 browsers will (probability 0.7) reach the
market beach this year. They will finally support CSS1 that allows you to
have HTML+CSS FOs interpreted natively in the browsers. But the market
renewal will take a certain time. To gain 90% penetration of the new version
this will take approx 2 years. Until then, because we don't have a 100% or
near that number, we still have to send documents in HTML format that is
supported by nearly 100% (not really but close +- 10% for v 3.2). So for a
certain time CSS will do the job for the early adopters in the client side
but classic HTML for the majority. To reduce the XML market introduction
cycle, XSL transformation part is crucial. The browser market is closed for
small guys (just talk to Opera people about this for a moment). The server
side XML->HTML transformation is more open. Microsoft do not own the major
market share on this side. At least 60% is owned by apache. This is a space
where small player can introduce their product. Big guys do not have
motivation to rush in this area they already make money with the market as
it is. Small guys yes they are motivated, they have everything to conquer.
And by the way, everybody as consumer gain in the process.
<Conclusion>

So, CSS can fulfill for a certain time the FOs part. A note: you can
generate with "XSL transformation" XML to HTML + CSS . I personally tried
this combination. I took a XML document and created HTML with CSS for
rendering So I used HTML FOs augmented with CSS. So you have actually a set
of Formatting objects you are sure that will be rendered in any browser
(then use HTML formatting objects). You can also limit to a sub market of
early adopters or people having the latest browser (then use HTML + CSS).
With version 6.0 (and this version own renewal cycle) we can target to have
XSL with natively rendered (in browsers) processing. But just add 5.0 market
penetration cycle to 6.0 penetration cycle market and we are not yet to the
fact that a browser includes XSL FOs. Imagine, we will just move this year
(not early adopters but the main stream market) from plain HTML to HTML +
CSS and dynamic HTML. So no problems, short term we have HTML fOs and
HTML+CSS FOs. For early adopters XML +CSS on browsers but no local scripting
so HTML + CSS has an edge here. See, when the problem is taken from its
broader market perspective, things are different.
</Reply>

Regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com
</Reply>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list