- From: Graham Seaman <graham@theseamans.net>
- Date: Thu, 24 Apr 2014 09:30:23 +0100
- To: xproc-dev@w3.org
On 24/04/14 08:29, Graham Seaman wrote: <snip> > I saw the extension library included a schematron wrapper with > parameters. On looking again, it seems I imagined this. Must have got it mixed up with another file. Sorry. Graham > 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 09:25:07 UTC