- From: Florent Georges <fgeorges@fgeorges.org>
- Date: Thu, 7 Feb 2013 10:15:24 +0100
- To: "Imsieke, Gerrit, le-tex" <gerrit.imsieke@le-tex.de>
- Cc: xproc-dev@w3.org
On 1 February 2013 22:27, Imsieke, Gerrit, le-tex wrote: > On 2013-02-01 19:08, Florent Georges wrote: Hi, Thanks Gerrit. >> But in XProc, there is no import priority, and one can >> never override any step. If two steps are found with the same >> name, that is a static error. >> How would you then offer extension points the same way in >> an XProc library? > I sometimes wish that p:import work like that. It'd be > interesting to hear the WG's reasons for choosing non-cascading > (or non-inheritable), non-overwritable import. I'm just guessing, but facing the complexity of xsl:import rules and priority, and willing to have a simple XProc 1.0 rather quick could be a reason... > I'm inclined to use Calabash's cx:eval with a dynamically > selected pipeline as an alternative extension point mechanism. Interesting, I didn't think of cx:eval. So basically, if I want the user to be able to filter one of the intermediate results in a step, he can pass the name of a step as an option (as a string), and the step includes: if filter-step is passed eval filter-step with appropriate options else identity By the default, filter-step is empty. The library can even provide a default implementation, so the user can in that case actually override part of the step implementation. Regards, -- Florent Georges http://fgeorges.org/ http://h2oconsulting.be/
Received on Thursday, 7 February 2013 09:16:12 UTC