- From: Dave Pawson <dave.pawson@gmail.com>
- Date: Mon, 22 Apr 2013 15:38:41 +0100
- To: public-ppl@w3.org
On 22 April 2013 14:22, Tony Graham <tgraham@mentea.net> wrote: > 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? Just events. Perhaps you could list the ones you currently envisage? My concern is the stylesheet writer perspective. Too many and it's unworkable. > >>>>> 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. +1 -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk
Received on Monday, 22 April 2013 14:39:16 UTC