Re: extensions to FO

> Since the source is not an fo but a way to produce it, be it
> a pair of xml/xsl files or a database and a query.

I'm not sure that makes much difference in practice. I agree that
an FO file with inlined MathML is not guaranteed to work on any  FO
processor, but whether I give you an FO with inlined MathML or a
stylesheet that is going to write the same, I don't see that
it makes a lot of difference. In either case you have to deal with it
(perhaps by rejecting the whole document, which is an acceptable
response)


> An XSL FO formatter must not be fed with non-fo elements unless it
> explicitely agrees to accept them.
presumably if the WG gets round to writing a W3C schema for FO, they'll
be forced to be more explicit about the intentions towards elements not
in the fo namespace. 

But If (to take a real example) I were to have a product documentation
consisting of two 700 page pdf files including mathematics, am I supposed
to wait until XSLFO 2.0 to support bookmarks and Mathematics, or is it
better to experiment with extensions which enable the basic mechanisms
of FO to be tested "for real" but at the same time produce an acceptable
result for production documentation.

If there's going to be extensions, surely it does no harm if the
different FO products could at least be aware of each others extensions
and support them or gracefully fail them. It doesn't necessarily mean
that the norm is for people to be trying the same FO document on
multiple systems it just helps sketch out ideas for input to 2.0, and
helps people write stylesheets that are not tied to one back end.

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.star.net.uk/stats.asp

Received on Sunday, 4 February 2001 12:29:17 UTC