W3C home > Mailing lists > Public > www-xsl-fo@w3.org > February 2001

Re: extensions to FO

From: David Tolpin <dvd@renderx.com>
Date: Sun, 4 Feb 2001 21:43:06 +0400 (AMT)
Message-Id: <200102041749.VAA25565@mix.aua.am>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:52 UTC