Re: Venting

Marcus Groeber wrote:
> 
> Of course, having both in one rec would increase the pressure on browser
> makers to implement FOs in order to be able to claim "100% compliance".

If there were XTL and XSL, then browser vendors would feel pressured to
implement *XSL*. With the transformation part removed the only meaningful
definition of "XSL" would be the application of that transformation
language to flow objects. Implementing "XSL" without the flow objects
would be an oxymoron: there would *be* no such thing as XSL without flow
objects.

Now if Microsoft claimed to only support XTL and not XSL then we would
have a much clearer picture of what they will and will not support than
today when the definition of "XSL" is very vague (because of all of the
half-implementations).

> I could even see FOs getting a life of their own as an XML-based page
> description language that doesn't necessarily have to be generated by
> XSL transformation at all. Not sure if this is really a good thing
> because it would have a lot of overlap with things like PDF, TeX or RTF
> (then again, none of these can be generated directly through XSL), but
> splitting the two would open up that possibility to "the market" as
> well.

I agree, and I don't see anything wrong with it at all. Also, if the FO's
were split off it would be easier to see exactly what they do or do not
provide beyond what HTML and CSS provide today. I must admit that I'm
relatively agnostic on this fo: vs. HTML issue. How does the world come
crashing to a halt if we spell <fo:block align="center"> as <P
align="center">. Isn't it the sophistication of the *formatting model*
that matters?
-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

"Remember, Ginger Rogers did everything that Fred Astaire did,
but she did it backwards and in high heels."
                                               --Faith Whittlesey


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