Re: Adapt Saxon-CE event model to XSL-FO?

On Fri, April 19, 2013 3:38 pm, Dave Pawson wrote:
> On 19 April 2013 14:17, Tony Graham <tgraham@mentea.net> wrote:
...
>>> Issues (possible, if I guess right).
>>> One event per match? Hundreds of match strings?
>>
>> XSLT 2.0 allows multiple tokens in xsl:template/@mode and multiple
>> alternatives in xsl:template/@match, so there's scope for templates that
>> are usable in multiple contexts.
>
> I was asking how many matches you envisaged rather than xslt
> capability. A limited number seems workable, dozens/hundreds
> seems unworkable to me?

Sorry, I misunderstood, and I'm still not sure I understand.  Do you mean
how many event types or how many contexts or how many event/context
combinations?

>>>> If this takes off, I would also expect more appearances of @role [1]
>>>> and
>>>> @id [2] in FO documents just so it's easier to write event handler
>>>> @match
>>>> attributes.
>>>
>>> So do you see the @match being to source document attributes?
>>>   ... I was thinking of 'matching' (wrong word) on formatter events?
>>
>> @match would contain XPaths that would be matched against contexts in
>> either the FO tree or the area tree.  The formatter events would be
>> represented by @mode tokens.
>
> In which case you've lost me Tony?

As in the original post, the formatter event you're matching on goes in
xsl:template/@mode.

...
>> If you went the callback route, it could be something like:
...
>> but both alternatives seem like more work to write and to maintain than
>> letting the formatter work things out as in the original proposal.
>
> I agree... bit like saying, for every block of text, 'if this goes
> wrong'.....
>  I.e. not workable, unless iterating round an edit/test cycle?

Really not the declarative, let-the-processor-decide flow that we're used
to with XSLT, so let's agree that it's a dead-end.

>>>> What happens when, e.g., multiple cells in a table row would each
>>>> cause
>>>> the table row to split and there's an event type and event handlers
>>>> defined for that sort of event is anybody's guess at this point.
>>>    Does your 'ripple up the source tree ' model work here?
>>>    As with the list above?
>>>>
>>>>> Thinks. Is it possible to categorise 'events' and provide options?
>>
>> The type of the event becomes the mode name.
>
> I'd appreciate more description on this? I don't see how this might work.

It's what I've been describing all along, and what Saxon-CE describes for
how it works.

>>>> So another part of event handling by the XSL formatter is determining
>>>> which event to handle first, since you don't want to first handle an
>>>> overflow on the last page if the next event handler to run is for an
>>>> overflow on the first page and that event handler changes the areas
>>>> such
>>>> that the overflow on the last page no longer occurs anyway.
>>>
>>> Yikes. Good point. First page to last, bottom to top?
>>> Something like that?
>>
>> Probably, though I'm not sure if you mean bottom of the tree or bottom
>> of
>> the page.
>
> <grin/> Neither! bottom to top of the fo tree was my thought, least
> area to entire document?

It seems to me that the first approach to try would be document order of
the area tree.  Experience will then show whether it's better to handle
events from sub-areas before events from their ancestor areas.

Regards,


Tony.

Received on Monday, 22 April 2013 13:23:01 UTC