Re: [XSL-FO] Two-Pass FO Processing and Evaluating the Applicabilityof FO to Layout Requirements
It is true that for an incremental interactive XSL-FO processor, for example,
it wouldn't be very useful. However, the "external-destination" of
"fo:auxilary-resource" represents a URI rather than a file. As a consequence
it must be resolved using regular XML entity resolving techniques. A more
incremental processor, for example, could systematically resolve them to
nothing, while a batch type of processor could take into account its environment.
The specification could also say that it is perfectly legal to ignore the
The idea of introducing EXSLFO is, however, interesting. If there is enough
momentum, some new peripheral features could still be implemented in a
standard way. I have therefore joined your list.
W. Eliot Kimber wrote:
> Werner Donné wrote:--
>>The TeX auxilary file idea would go some way to solving this issue.
>>Adding it to XSL-FO wouldn't have an important impact on the XSL-FO
>>architecture. See also http://lists.w3.org/Archives/Public/xsl-editors/2001OctDec/0014.html.
> I agree that the auxilary file approach would satisfy the requirement
> but the Subgroup disagrees about the impact on the FO architecture.
> The proposal you make above is essentially the same as one I made. We
> discussed this in the subgroup at one of our face-to-face meetings but
> the concensus was that this was too dependent on specific implementation
> choices as there is, for example, no requirement than an FO
> implementation work in such a way that the auxiliary information could
> actually be output (for example, there's nothing in FO that presumes the
> ability to access files (as opposed to Web-based resources) much less be
> able to write data to some storage location). That is, the auxiliary
> file approach, at least the way you and I envision it, essentially
> requires a sequential batch-style process. So the subgroup rejected the
> requirement as being architecturally incompatible with XSL-FO generally.
> However, FO implementations like XEP, FOP, and XSL Formatter are all
> sequential processors that could easily (I think) output this type of
> auxiliary information. But so far I have not succeeded in getting any
> vendor to consider this type of extension.
> The general requirement is documented on the EXSLFO site,
> http://exslfo.sourceforge.net/requirements.html, although there hasn't
> been much discussion there for a while. [Also, the XSL-FO 1.1 activity
> has largely overtaken the current EXSLFO activity such that most of the
> requirements documented there are now addressed in XSL-FO 1.1--I haven't
> taken the time to update the site to reflect that fact.]
> FYI: EXSLFO is modeled on the exslt activity. It is a place to discuss
> and capture new requirements for XSL-FO and in particular for
> requirements whose solutions would fall outside the scope of the core
> standard and that therefore can only be addressed as FO extensions, such
> as PDF-specific features or layout-aware processing features.
> It also serves as a place to discuss general FO requirements in advance
> of formally submitting them to the FO subgroup for consideration in
> future versions of the specification.
Werner Donné -- Re BVBA
tel: (+32) 486 425803 e-mail: werner.donne@...