RE: Formatting Objects considered harmful

Subject: RE: Formatting Objects considered harmful
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Sat, 17 Apr 1999 12:05:57 -0400
Hi John,

<Comment>
As for those who've never used either PDF or FOs, I still don't quite
understand why they'd *want* to use FOs alone. To grok XSL FOs, they've got
to grok XML itself. By the time they get that far, if they remain
determined to create FO castles in the air, as it were, neither we here nor
the W3C will be able to stop them. I don't want to expend any energy to
stop them. There won't be enough of them to worry about.

So I guess my main question is still, WHY would someone want to build
documents in an FO-only way? I still think this is a straw-man argument --
it attacks the spec for failing to legislate against an extremely unlikely
crime... a crime almost certain to be committed by no one but those on the
Dadaist fringe of content developers.
</Comment>

<reply>
I think that this danger can happen only if a major manufacturer with a
sufficient market share publish a product which produces FOs. If we look at
these manufacturers:
a) Microsoft - they choused an other path ( a mix of semantic XML, non
semantic XML and HTML+CSS)
b) Corel - They choused a XML/SGML/HTML path.

I think the probability that this happens is quite low. However, I see
tremendous resistance to go from HTML to XML for massive publications (at
least for several years) on the web. However, I see XML strongly making its
marks on EDI and consumer e-commerce. Also, XML may be the next step for
SGML shops because the tools are cheaper than actual SGML tools and still
have SGML advantages. A major argument for SGML shop is the huge difference
in cost of a SGML aware browser and a XML aware browser. I think, that we'll
see a transition period where SGML/XML parser will be included in actual
browsers. This could allows the inclusion of Hytime and TEI link
architecture. However the main difference would be that the rendition engine
would be a  browser (IE or Mozilla) instead of the Synnex engine (which is
actually a monopoly for SGML rendition engine - using, of course the same
criteria to define a monopoly as used against Microsoft).

For Browsers, the underlying model (where a lot of investment have been
made) is HTMLDOM or XMLDOM + CSS. In fact, If you look at Microsoft or
Mozilla engines, both made or are making significant development investments
in CSS objects. For Mozilla especially, the cost to move to new FOs is
simply not affordable because there is no big pockets behind the project
anymore . From the Microsoft perspective, they could embrace XSL FOs to kill
once for all the competition but this would be a big strategic mistake that
I doubt they would do now. As Intel is doing today, they now have to keep a
certain level of competition to prevent Feds intervention. So, knowing that
supporting XSL FO would kill Mozilla not able to re-invest energies to start
new development on a different FO model. I doubt they would make that move.
So, my bets are that CSS objects are here to stay for a long period of time.
CSS being an easier language to learn and that could easily wrapped with
property pages, CSS popularity will re-enforce this situation. XSL could be
used for more sophisticated formatting or for off-line formatting and
therefore would compete with an other standard language like DSSSL and the
two actual main manufacturer owned languages omnimark and balise. These two
language still have a lot of advantages like being able to link to
relational databases. XSL and DSSSL are weak compared to these languages on
this point. On the server side, xsl will have to face some strong
competition form Perl and ASP.

XSL language may have tremendous opportunities but its strong actual
grounding in style formatting, may also be its worse enemy. However, in the
future, XSL may evolve toward pattern matched processing or event based
processing for server side scripts. Because on the server, there is no
strong standards for server side processing, XSL may have strong potential
there. Also, the popularity of XML EDI may require server side processing.
How long will it take for XSL to move from a simple style language to a
server side script language. I don't know. But this is where XSL may have
the greatest opportunities.

I do not want to say that XSL is doomed to failure. No, just to say that if
we look at the marketing dynamics, the time it takes for standard organism
to learn and react, the goals of the players bringing real stuff on people's
desktop, XSL and either its FO or transform part have to be thought within a
broader perspective. This does not remove the qualities of this language but
I just try to put things into the bigger system they are part of.

Conclusion: I am not too afraid by XSL FOs and their bad usages. I am more
afraid of the lost standardization possibilities lost because XSL is
restricted to a simple style language. Languages like omnimark (also envent
based or pattern matched languages) showed that linkage to data base can
make the whole difference especially if you have to process a XML EDI
document. I am more afraid of the standard organism learning curve an the
natural balkanization that occurs because of the charts, consensus to build
with members, etc... How long, if can take for the community to recognize
XSL as a great candidate for server side scripting standard? I don't know?
So, I'll continue to fill my notebooks with historical facts and continue to
observe the big system where this thing happen and how some decisions may
impact our computer world.
</reply>

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