RE: Venting

Subject: RE: Venting
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Wed, 10 Feb 1999 14:21:47 -0500
Hi Guy,

I'll tell you my biggest concerns:

a) That the final spec that includes formatting object won't be out before
next year.
b) There won't be any browser that includes XSL FOs until one or two years.
c) CSS is easier  to use for Formatting objects on the client side and
browsers are catching up CSS1 full implementation. So now imagine for CSS2.
d) A spec is nothing only implementations created by manufacturer is
something (a pragmatic point of view). So, Why get mad about manufacturers
who created real stuff? big manufacturers have interest that the spec isn't
fully completed until there ready. Small manufacturer don't. Status quo
favor big manufacturer and re-enforce actual status quo situation on the
market. So, the question is: all ISV happy that more and more the software
ecological system is more and more occupied by single specie? Status quo
encourage this by putting delays in the process.


But also I'll tell you what can re-assure me:
a) nothing speak more than action. If 90% of all XSL implementations
including the big guys implementation are XSL transformation then that's it,
for most of the population XSL is transformation only. Manufacturer should
not refrain themselves from calling their implementation XSL even if it only
contains the transformation part.
b) XSL will be more popular on the server than on the client. CSS will be
more popular on the client. XSL will be mostly used to transform XML into
HTML+CSS for very practical reasons.
c) The majority of the market on the server side is owned by apache and
therefore there is room for manufacturers others than Microsoft and AOL
(Hoops. sorry, Netscape) to provide XSL engines and that is good for ISVs.
As soon as XSL reach the big developers market, demand for new features will
abound and these engines will move from ideal driven to market driven.
d) W3C won't necessarily favor small manufacturers (ex: look at W3C style
sheet page, only certain manufacturers links are present and do not reflect
all current implementations. There is a certain censure) W3C will favor
first its member and we shouldn't expect more it is not in W3C gene to do
so. If manufacturers do some form of sane coopetition they have more power
than they think they have.
e) XSL transformation already showed its utility and with some ingenuity
could do a lot more. Again, action talks, concrete example will provide more
to potential users than concise specs.

So, we demonstrated that our group could be as divided and diverse as W3C
workgroup. This is a good thing, we don't suffer from group think. If this
group where under IETF hospices it would have already improved a lot the
specs. In one word, I am impressed by the quality of this group.

Now practical things:

I am experimenting on domain language translation using XSL, so far, I am
surprised by the potential this language has for this. If section 2.2 stays,
or if implementations keep that (because it is a good thing) we have
certainly some potential here.
I am using more and more HTML+CSS as a formatting language. I like the
voyager module segmentation that is re-using Hytime modele mechanism. So, I
can pick the proper formatting object from these modules. So, in my
practice, I got used with XSL for transformation and HTML+CSS for rendering.
I don't care about XSL fOs they don't give more than what I have now with
HTML+CSS and I don't have again to learn new stuff but re-use my knowledge
of HTML+CSS (If we speak of knowledge management, knowledge re-use is also
very economical and I guess that a lot of Web developers will think the
same). Anyway, a browser understanding XSL FOs is not until 2 to 3 years
from now and a market having 90% browsers with XSL FOs not until... You got
the point?
I am also experimenting to create macros that implements Formatting objects
for other formats (tex, rtf, etc...) the idea is to use these macros within
templates to create the desired output. From the specs (actual, as written)
it should be feasible. I am trying this on different implementations, so
far, didn,t went far on this, most of them do not work well with macros.
(macros could be very demanding for XSL interpreters as I already
experimented with DSSSL macros that blown away Jade).
In one word, as long as already existing implementations (with source code
or binaries) support transformation, what I really use is the transformation
part. So, for me, actually as it is for 90% or more of actual users of XSL,
XSL is de facto a transformation tool and CSS+HTML a formatting/rendering
tool.
I am also writing a paper that compare CSS, XSL and DSSSL. To write this
help me a lot to understand the strengths and weaknesses of each. And also
by keeping a eye on practical ends, put these into perspective like: using
DSSSL and HTML+CSS as formatting objects, same thing for XSL, The difference
I have if I use HTML formatting object stand alone and the same objects with
CSS (either with the style attribute or the class). The fact that actual
browsers formatting language is HTML+CSS put transformation language into a
different perspective, As soon as DOM 2 is implemented, a browser may be
used to render any language and that is interesting too because it opens the
door to other formatting/rendering languages.

also on the work articles on: How to use browsers to create SGML electronic
books (like ATA 100, etc...), XML based e-books, How to use topics maps to
organise a collection of XML/SGML documents (also alternative formats like
PDF, EPS, etc..)

In all these activities I use XSL as a tranformation tool because I have
plenty of tools to experiment with. This is not the case with XSL formatting
objects. Sincerely, Guy, did you do any stuff with XSL formatting objects? I
doubt. So, XSL transformation has already a big momentum and that is not the
case with XSL formatting objects and that is obviously for practical
reasons.

Lessons to remember: Actually if you look at most sites talking about dsssl
they also mention Jade as the implementation (also in other parts of the
world they have other Jade derived tools). Jade is often 99.5% of the time
presented as a DSSSL implementation even if it don't support the
tranformation part. So I don't think that manufacturers should be afraid to
call their implementations XSL. We already have jurisprudence that the
market give the name to real stuff not the piece of paper that inspired
this. So let's call the transformation part XSL and for most people,
formatting objects will be a version 2 and probably XSL will be more popular
as a tranformation tool. W3C get a good occasion to show some common sense
but a chapter is not governed necessarily by that but also by political
pressure of its member and the limitations of the charter. Manufacturers int
his story already showed that they have common sense. Of course, they have a
market to serve.

Now let's go back to my lab, I repect your desire for status quo and I still
support Paul's efforts to gets things moving and clarified. Always two
forces present in any group. My hope, the future of XSL is more in the hands
of those implied in the action.

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


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


Current Thread