Re: Area tree formats

On Sat, March 1, 2014 5:55 pm, practice innovation wrote:
> When implementing the FOP extension I just woke up to the different area
> tree formats delivered by FO processors
...
> If you want to manipulate the area tree, you need to implement one and the
> same functionality for each FO processor.

Yes.

> Of course you can implement some functions like "block-by-id" in
> ppl-extensions.xslt, but manipulating an area tree in common way can't be
> handled here.

Yes.

> As I don't want to implement functions twice, if it isn't necessary,
> area-tree function should deliver a "standard" area tree, which is
> transformed by the extension directly. And if so, there should be a
> function, which transforms it back to processor's tree format.

I was in complete agreement up until you said you want to transform it
back to the processor's tree format.  To be able to transform from 'our'
area tree to every processor's area tree, 'our' area tree would have to be
a strict superset of every processor's area tree rather than, e.g., the
commonly useful subset, and every time we support another processor, we'd
risk having to rewrite the area tree model to accommodate the new
processor's format.

An alternative would be to annotate each processor's area tree XML with
attributes in 'our' namespace indicating what the area is in our model
and, maybe, indicating the name of the ID attribute in the processor's
markup.  We could then write the accessor functions in terms of those
attributes in the augmented area tree XML.  Getting back to the
processor's area tree XML would be a matter of stripping those attributes
(and wouldn't be needed if the processor was going to ignore them anyway).

To do it all Properly, we'd want to write one or two CG reports detailing
firstly the area tree model defined in the XSL 1.1 spec, since it's
currently spread across the definitions for various FOs, and also the
model for our view of the area tree and how it relates to the XSL 1.1
view.

I was also at a loss for why you'd want to get back to the processor's
area tree, but it eventually occurred to me that it would be useful for
the first three scenarios from Kevin's email last week that I was too
quick to dismiss.  Sorry, Kevin, but I've never yet had to feed an area
tree to a formatter other than for testing extensions to a formatter.

Regards,


Tony.

 --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  -- --
Mentea       XML, XSL-FO and XSLT consulting, training and programming

Received on Sunday, 2 March 2014 16:42:15 UTC