xml-dev - RE: Which browser supports FO also

[Didier PH Martin <martind@netfolder.com>]

Hi Steve,

Steve said:
Didier, you and Jon Bosak should have a talk! He gave a speech at
XTech last year that pleaded for us to not give up on FOs. FOs do not
replace HTML. Rather, HTML just becomes one possible output back-end
from an FO processor. Granted, you would lose some fine control of the
HTML production, but for many applications that loss would be fine
when weighed against the benefit of maintaining a single abstract
formatting specification.

Didier replies:
Speaking of giving up, I am probably a good example of a guy not giving up
since I am working hard on a DSSSL-2 specification :-))
So, I never got in my mind to say to the people to give up. My comment was
more a status of the current situation. A status with a sentence beginning
with " here is the current state of...." instead of a more inspiring one
like "I have a dream....". This is why I used probabilities in my
statements.

This said, let me, for a moment, bring some experience I gained from the
hundreds of hours invested on thinking about the issues of styling. The
actual DSSSL and also XSLFo suffer from the same limitations.
a) Their visual model is based on a page model. Notice here that I mentioned
the word "visual".
b) both XSLFo and DSSSL-1 lack the "aural" dimension. This is particularly
important if you consider that VoiceXML could potentially become a commonly
used type of browsing tool is car become equipped with VoiceXML enabled
equipment. Consider that GM is currently working on that (more precisely
OnStar). That other car manufacturers are seriously considering wireless
connection and "aural" document rendition. Expect that the 21st century car
is a network connected car. In the light of this important innovation, the
current XSLFo and DSSSL-1 "visual" models are not of great use for "aural"
rendering.

So, some glucose should be used to feed some mental activities on this issue
:-))

However, DSSSL-1 brought an important feature, the concept of "rendering
driver". In this type of architecture, a single object model is presented to
the designer and "drivers" perform the translation from the model into other
models. For example, a "paragraph" can be translated into a <div> or a <p>
object in the case of HTML and into "/p" for an other and so forth. Also, a
rendering object can be mapped to a procedure, an API etc...

In this sense, it can be tremendously useful to have a single model to work
with and to have "drivers" to perform the translation. This brings to
reality the vision of "I have a dream...of a universal object model....".
The problem that may occur when we try to realize this dream is that the
superset model become:
a) too complex
b) too restrictive
In a) the feature set tries to embrace the most complete language. One of
"drivers" is becoming the reference language and the question is then "why
not take this language as a reference?". In b) the feature set is more
limited than one or several language encapsulated by the "drivers". In that
case, the "universal" language is less useful that one of the "driver
encapsulated" language. So do try to implement the least common denominator
or to imitate the most complete language. The result should be something
more balanced. This is a difficult design constraint.

An other point, witch, in our case, is to  be considered also is a question
of knowledge management. To make the story short, a knowledge management
perspective takes into account what people know and thus how this knowledge
is translated into action, how this knowledge is economical (is there
something they should know that will decrease the costs).

The goal we try to reach with a "universal" rendering language is to reduce
development costs by having a single piece of code to write. OK I'll repeat
it because this is the main reason: The goal we try to reach with a
"universal" rendering language is to reduce development costs by having a
single piece of code to write

Actually, millions of people know about the HTML language, from them, to
graduate from HTML 201 to XHTML 101 is not a big deal since most of their
knowledge is still useful. So, from the knowledge management point of view.
We have greater chance of success to have these people to enter in the XML
world through the XHTML. For those who already made the shift to the
independence of the model and the view, this is an other ball game. They
simply live in a different world, they made the move to the other side of
Alice's mirror.

But what is important here to notice is the "herd" effect as most of us have
experimented throughout our life. The most recent great example if probably
the stock exchange and the insane prices paid for e-stocks. Why is this
popular? more people get it because everybody want it, and everybody want it
because every body get it :-) When you have millions of people knowing a
language, even if this latter is limited, the main argument of these people
can be: "can you improve it a little so that it does what we want". The
least thing these people wants to hear is: "forget it, and start to learn
something new". IN the case of the latter, people need to face a wall or
have good economical incentives to do a move.

Can XMLFo can make these people to switch? Now again, let's take a
perspective from the experience we gained from the last 4 years with DSSSL.
No I promise, I won't do like my grandfather and talk about the trenches and
Verdun :-)) We discovered that the main problem DSSSL got is simply not to
be embedded into the other products, like for instance, the SGML/XML
authoring tools, the HTML/XHTML browsers. So to speak, the incentive to
learn and use is mostly driven by the browser and authoring tools
manufacturers. Or actually, it is also in the hand of people with a lot of
free time and who are willing to design/code for no fees. If the "gizmo"
language is included in all browsers and all authoring tools, then this
"gizmo" language is interesting for the people. This is the network effect -
everybody has it, therefore I like it, I like it because every body has it.
So, independently that either DSSSL or XSLFO is good or bad, the advice we
can give to people who want to make it a success is:
a) embed the language in an open source browsing tool - for instance in
Mozilla - Any volunteers?
b) embed the language in an authoring tool - For instance, a volunteer based
open source project - any volunteers?
c) embed the language in a vendor browsing tool - for instance Windows
Explorer - Microsoft will you do that? does your market wants that? is there
any incentive for you to do that?
d) embed the language in a vendor authoring tool - For instance in
arbortext, Hot metal - Hey guys will you do that? are your customers asking
for it? are you ready to take the risk? (the last word is important here -
risk taking for commercial ventures).

If (a) to (d) is fulfilled or if any item (from (a) to (d) ) reach big
numbers (of people), then this is it, no question asked if XSLFo is good or
bad, a great software or a so so tool. It is a de facto success because of
the herd effect. Because of the network phenomenon. Implied herd effect
Reasoning "if all these guys are investing in it - it should be good...".
Theorem: the value of a software is proportional to its number of used
copies. The more you have, the most valuable it is. its value is
proportional to the square of its number of used copies. The function here
is an exponential. Or something more like a Gauss curve (a bell curve). When
a new kid on the block appears, and become more popular, this is the
opposite, the value is decreasing with the same proportion but in a negative
manner.

Question: Where is HTML located? Still in the ascending curve but challenged
by the new kid XHTML. As soon as browser manufacturers include new modules
(like for instance the SMIL time module), the value of HTML decrease and the
value of XHTML increase. Mostly also due to the fact, that XHTML is simply
the same king with new clothes.

Where is located XSLT and XSLFO?: still with the early adapters and
visionaries. It didn't crossed the chasm yet but may as soon as both Mozilla
and Microsoft browser support it. These two guys are the market gateway,
like it or not.

Is XSLFO popular? Observing the industry, I didn't saw this kind of support
yet. I should say that there is some exception like RenderX, a company
taking the "risk". Does XSLFo does the job? sure it does. And I hope people
will use FOP or RenderX or OpenJade as tools to get their job done. Will
these tool find a market? sure, they already have. There is a niche market
of people not affected by the herd effect and ready to learn something
different - marketers call them : early adopters or risk takers. But to get
to the mass market, the big numbers, we need to cross the chasm and to cross
the chasm, we need at least (a) and preferably (c). Otherwise, XSLFo will
fulfill the needs of a niche market and would never jump over the chasm.

Advice:
If you see that XSLFo fulfill your needs, go for it and do not wait for the
herd. If you want the silver bullet, a kind of thing like "code once, style
everywhere", sorry, we do not have that yet. Should we give up and stop
searching for this silver bullet? No. As long as some people still search
for it, the progress is not over.

Conclusion:
What is needed though is a fast XSLFo to HTML translation tool in addition
to XSLFo to PDF that we have today. Someone ready to take the torch? Also
ready to give it to make it work and give it Mozilla? If yes, That's it,
XSLFo is a success story.

Sorry instead of starting my message with "I have a dream...." I just said
"Here is a job to be done...". The time now is for execution, not discourse.
The result of the action will make this language popular or not. So, like
they say in the army, it will be hard, you may die but you'll get the
glory.... Volunteers? If so, drop me an email, the OPenJade project has
already most of the drivers, what we need now is the XSLT part and FO to
driver translation. If action for you is more important than politics here
is my email : martind@netfolder.com.

cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: XML Europe (http://www.gca.org)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)
Products: http://www.netfolder.com


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************