W3C home > Mailing lists > Public > xproc-dev@w3.org > February 2013

Re: Extension points in an XProc library

From: Imsieke, Gerrit, le-tex <gerrit.imsieke@le-tex.de>
Date: Fri, 01 Feb 2013 22:27:37 +0100
Message-ID: <510C3349.8040109@le-tex.de>
To: xproc-dev@w3.org


On 2013-02-01 19:08, Florent Georges wrote:
>    Hi,
>
>    In XSLT, if a generic stylesheet wants to offer a extension
> point, where an importing stylesheet can "plug" some processing,
> it can call an empty named template, that the final user can
> override in his own stylesheet by providing some implementation
> of it.  Or anyway a user can always override a template rule.
>
>    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. Itd be interesting to 
hear the WGs reasons for choosing non-cascading (or non-inheritable), 
non-overwritable import.

Although I dont like it very much  because of the inevitable 
multiplexing/demultiplexing noise, and because its non-standard  Im 
inclined to use Calabashs cx:eval with a dynamically selected pipeline 
as an alternative extension point mechanism. Example: 
https://subversion.le-tex.de/common/pubcoach/trunk/xpl/evolve-hub.xpl

Gerrit
Received on Friday, 1 February 2013 21:28:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 1 February 2013 21:28:14 GMT