Re: Initial impressions [was: Re: try/catch with messages]

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