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

Re: Extension points in an XProc library

From: Florent Georges <fgeorges@fgeorges.org>
Date: Thu, 7 Feb 2013 10:15:24 +0100
Message-ID: <CADyR_r1Mw5MZmX2iCAN9FW+cz318cNF7bhF-pxKy6fONTdZ3jg@mail.gmail.com>
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:


  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

  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.


Florent Georges
Received on Thursday, 7 February 2013 09:16:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:10 UTC