- From: Graham Seaman <graham@theseamans.net>
- Date: Thu, 24 Apr 2014 08:29:13 +0100
- To: xproc-dev@w3.org
The messages work fine. Thanks again. I saw the extension library included a schematron wrapper with parameters. Should this work before your calabash patch (https://github.com/ndw/xmlcalabash1/pull/146) goes through, or does this do something different? I have provisionally left some schematron variables hardcoded in the .sch file, assuming I wouldn't yet be able to pass them from xproc. Graham On 23/04/14 12:49, Imsieke, Gerrit, le-tex wrote: > For messages, you may use cx:message [1]. Just import this: > <p:import href="http://xmlcalabash.com/extension/steps/library-1.0.xpl" /> > > Usage example (taken from [2]): > <cx:message> > <p:with-option name="message" select="concat('COVER: ', > /epub-config/cover/@href)"> > <p:pipe port="meta" step="create-ops"/> > </p:with-option> > </cx:message> > > You’ll find plenty of (more or less) working XProc examples linked on > our transpect page [3]. One of the less complex is the CSS→CSSa > converter [4]. Please note that you’ll have to check it out with an SVN > client to get all externals. > > Gerrit > > [1] http://xmlcalabash.com/docs/reference/cx-message.html > [2] > https://subversion.le-tex.de/common/epubtools/modules/create-ops/xpl/create-ops.xpl > > [3] http://www.le-tex.de/en/transpect.html#transpect-modules > [4] > https://subversion.le-tex.de/common/sandbox/css_expand_standalone/trunk/ > > On 23.04.2014 12:39, Graham Seaman wrote: >> On 17/04/14 11:33, James Fuller wrote: >>> Graham, >>> >>> nice job sticking with it ... xproc has a difficult learning curve >>> which we (as in the W3C XML Processing WG) are trying to address in >>> vnext. >>> >>> Be interested in your fresh impressions, to see what you found >>> confusing, useful , etc. >>> >>> cheers, Jim Fuller >>> >> >> I'd say the thing which has probably slowed me down most is an inability >> to do simple debugging easily: a p:message as an equivalent to a 'print' >> statement in other languages, or a more flexible p:log. >> >> I've now more or less managed to create the pipeline that I wanted. >> However, since this pipeline is meant to carry out a series of >> validation steps the difficulty in getting back diagnostic information >> when something unexpected goes wrong does limit its usefulness. >> >> Looking forward to seeing the new version! >> >> Cheers >> >> Graham >> >> >> >> >
Received on Thursday, 24 April 2014 08:24:00 UTC