- From: David Tolpin <dvd@renderx.com>
- Date: Sun, 4 Feb 2001 21:43:06 +0400 (AMT)
- To: davidc@nag.co.uk (David Carlisle)
> > 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) The stylesheet can be parameterized to output correct FO+extensions for different processors. It is a valid and standard use of XSLT. While there is almost no standard way to parameterize the resulting FO in the same way. > > 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. I agree. I did not mean there should not be extensions. What I am saying is that the only non-standard elements which should be accepted are those the formatter is aware of. If a formatter meets an unknown markup, it should stop, not skip. David Tolpin
Received on Sunday, 4 February 2001 12:47:49 UTC