Re: XProc things for our upcoming meeting

Hi Erik,

The F2F meeting will take place. I just created a Github project and a 
wiki: https://github.com/xproc/Workshop-2018-02

You should have write permissions, so feel free to add your suggestions 
here: https://github.com/xproc/Workshop-2018-02/wiki/Agenda-and-Minutes

Regarding your questions, maybe Achim, Norm (if available), and/or I can 
have a hangout with you next week.

Regarding moving the EXProc extension steps to the core step library, we 
already decided in London that we want to do this. Someone needs to it 
yet. 
https://github.com/xproc/Workshop-2017-06/wiki/Minutes#user-content-step-library

Gerrit


On 06/01/2018 11:53, Erik Siegel wrote:
> Hi all,
> 
> Our meeting 6+7 February in Prague is coming soon (and please tell me 
> it’s still on, otherwise I’ll be stuck in Prague for two days with 
> nothing really to do…). I hope you don’t mind that I open the discussion 
> about what should be on the agenda with some of my hobbyhorses.
> 
> Beside discussion points about XProc there is another thing: In the last 
> few months I’ve been working on a book about XProc and in doing that I 
> encountered a lot of things I would like to discuss or have clarified. I 
> hope we can find time for that (either during of outside the meetings). 
> If you’re interested I can send the latest draft of the book by the time 
> we’ll meet.
> 
> For on the XProc agenda I would like to propose to discuss at least the 
> step library:
> 
>   * The current step library seems very much like the V1 version to me.
>     I personally (so feel free to disagree) have a strong need for all
>     the EXPath extension steps functionality, _especially_ the ones for
>     working with files (directory overviews, delete, copy, move, etc.)
>     and zips (reading, creating). So: Are we going to incorporate EXpath
>     as-is, are we going to incorporate them as standard XProc steps
>     (which might be as simple as changing the step’s type namespace)? If
>     so as optional or mandatory step? Or do we keep them outside the specs?
>   * If incorporating zips is in, I would like to discuss a slightly
>     different functionality regarding writing them (feeding it with a
>     manifest that can also read from output ports). I have no idea how
>     difficult it would be to implement and of course that might be a
>     factor in the decision making.
>   * Could we add steps for (I know you can do this with custom steps,
>     but this is so common…)
>       o Recursive directory listings (just extend the current p:directory?)
>       o Tee-ing to a file (IMHO: an invaluable and very easy to use
>         debug tool. Much easier and more low-threshold solution than the
>         current proposal about diagnostics. We could have both). Add a
>         disable option to the step so you can easily switch it off when
>         not debugging.
>       o Something for creating a file/directory structure on disk using
>         some manifest. The manifest should specify where to write (path)
>         and what to write (inline XML, take it from an output port
>         somewhere, copy it from an URI, etc.). The same functionality I
>         would like to have for creating zips.
> 
> Another thing I’m specifically interested in are the /specifics/ of 
> importing function libraries from XQuery/XSLT.
> 
> On the clarification front I hope we can find some time to discuss this 
> and others:
> 
>   * Shouldn't the p:declare-step/@xpath-version be an xs:decimal?
>   * You need maps in a step's prolog for specifying output
>     serialization. But you can't use variables there, so these will be
>     “fixed” maps, specified in full at the location where they're
>     needed. Would it be an idea to allow variable declarations in
>     between p:input/p:output/p:option elements?
>   * Why is the @parameters on the p:load an AVT?
>   * What is the default value of @expand-text?
>   * The explanation of the serialization parameters is not very
>     detailed. Where can I find more information? (e.g. method is
>     unexplained and has no value list, what do the normalization-form-s
>     do, etc.)
>   * What is the default value of p:option/@required
>   * Why does the use of @pipe exclude the use of p:pipe, p:document and
>     p:inline on a p:with-input? Seems unnecessary…
>   * What does this mean with the p:inline: It is a static error
>     (err:XS0071XPS) if the content type value specifies a character set
>     and the encoding attribute is absent.
>   * I don't understand the example given for p:namespace. I must
>     honestly say I no longer understand p:namespace at all, even I
>     remember understanding it more-or-less in Aachen.
>   * What happens when on a p:load you set dtd-validate to true and the
>     doc has no DTD ref
> 
> Hope to see you all in Prague,
> 
> Erik Siegel
> 

-- 
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
gerrit.imsieke@le-tex.de, http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer: Gerrit Imsieke, Svea Jelonek, Thomas Schmidt

Received on Sunday, 7 January 2018 10:04:07 UTC