Chris Lilley writes:
 > Entries  should come complete with source code and be freely usable by
 > others. Entries should take an XSL FO tree (either read in as an xml
 > document or, if wished, by implementing the XSL transformation part and
this would be covered by an "FO to LaTeX" converter, and an
appropriate LaTeX style sheet? 

what is the target? screen? print? `anything in a Web browser'? ie a
PDF file? a browser plugin?

 > reading in the source XML document and the XSL stylesheet). Entries
 > should output a rendered view of the document, in accordance with the
 > intent of the XSL stylesheet. With demonstrably better rendering than
 > CSS2 can produce, the object being to demonstrate that XSL is more
 > powerful *as a style sheet language*. For example, implementing mixed
 > vertical and horizontal writing systems.
three problems.

 a) the XSL formatting objects are, so far, too weak to support any
 interesting formatting which would challenge CSS. unless you can
 promise the next draft will contain eg math and tables, I cry "foul".

 b) "demonstrably better rendering than CSS2". to do this, one needs
 a test document, surely, which exercises interesting formatting
 features.

 c) one may be constrained by limitations of the XSL FO's in their
 draft incarnation. suppose there *are* table FOs, but it turns out
 they can express no more than HTML tables - then one cannot
 demonstrate, surely, what the XSL formatter could theoretically do?

i am inclined to say that if no-one meets your challenge in a year,
then the XSL committee might as well turn the lights out and leave :-}

Sebastian


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