Re: result of A&Q at XML Prague preconf day

Jacob,

As an aside, I've seen a number of people in your locale (Paris,
France) in XProc ... there was some talk of getting together a 1/2 - 1
day XProc event in Paris.

Please give me a shout if you (or anyone else) would be interested and
I will start having a think about how to make it possible.

I think doing a workshop, with hands on training/examples would be a
good format, but ppl may want something a bit more formal ?

J


On 17 February 2014 15:46, Jakob Fix <jakob.fix@gmail.com> wrote:
> Hi Matthieu,
>
> you mention that you've converted all your existing pipeline to xproc. Given
> the working group's interest in making it easier for newbies to get started
> with xproc (as witnessed in Prague), a presentation at a future XML
> conference "from the trenches" on how you migrated to xproc would make
> perfect sense in my mind. Where I work we are still in the Ant phase, with
> some powershell mixed in, so I for one would be interested to learn more.
>
> cheers,
> Jakob.
>
>
> On Mon, Feb 17, 2014 at 3:32 PM, RICAUD-DUSSARGET Matthieu
> <matthieu.ricaud@igs-cp.fr> wrote:
>>
>> Hi all,
>>
>> Nice to see some of you at XML Prague. And really glad about Norman Walsh
>> presentation about Xproc V2.
>> In my company we are converting all our "perl/xslt/pieces of xproc" dev to
>> fully Xproc pipeline. It was a bit painfull but we are on the good way and
>> we are really happy with it.
>>
>> http://www.w3.org/TR/xproc-v2-req/ matches exactly our wishes (especialy
>> parameters and XDM values), but let's add a few ones if this is not too late
>> :
>>
>> 1) p:import
>> It would be IMHO really, really nice to have an import mechanism in xproc
>> just like XSLT.
>> That would allow to override some step just like we often do in xslt
>> (priority, precedence is so powerfull !)
>>
>> 2) Accessing serialization method (especialy for p:xslt)
>> One of the biggest limitation we had is to used our huge amount of XSLT
>> without refactoring them all.
>> XDM parameters in Xproc V2 should solve the problem of typed xslt
>> parameters that we use a lot.
>> The other part of the problem is about serialization : Xproc says "this is
>> my job, not xslt's ones". That's sound ok but how to deal with
>> character-maps in Xproc for instance (we use this a lot for epub
>> compatibility)?
>> What about xsl:result-document, ok we can access them from the secondary
>> output but how to serialize them properly (according to the named xsl:output
>> in the xslt) ?
>> We have made our own xslt step which is a kind of "hack" of p:xslt. (see
>> http://lists.w3.org/Archives/Public/xproc-dev/2014Feb/0012.html)
>>
>> For the moment the only information accessible within the secondary output
>> is p:base-uri() which here comes from the "xsl:result-document/@href".
>> In Xproc V2 it would be nice IMHO to access the serialisation options
>> something like "p:serialization-method()", "p:serialization-indent()", etc.
>> ?
>>
>> 3) Conditionnal options (kind of @use-when)
>>
>> Let's say I have "calculate" an option and I want to send it to a step
>> ONLY IF it's not empty ? that means more generaly using the default option
>> if the one I have calculate don't satisfies a condition. It seems I have to
>> use p:choose for this.
>>
>> For example :
>> <p:variable name="my_indent" select="...complex xpath..."/>
>> <p:choose>
>>    <p:when test="indent!=''">
>>      <p:store href="foo.xml">
>>         <p:with-option namet="indent" select="$my_indent"/>
>>      </p:store>
>>    </p:when>
>>    <p:otherwise>
>>      <p:store href="foo.xml"/>
>>    </p:otherwise>
>> </p:choose>
>>
>> If I have 10 options, then I have to make all the combination which become
>> a nightmare...
>>
>> In Xproc V2 it would be nice IMHO to have a way to say if an option must
>> be send or not (i.e. default behaviour) :
>> For example :
>>
>> <p:store href="foo.xml">
>>         <p:with-option namet="indent" select="$my_indent"
>> use-if="$my_indent!=''"/>
>> </p:store>
>>
>> or maybe more generaly having a "p:if" :
>>
>> <p:store href="foo.xml">
>>      <p:if test="$my_indent!=''">
>>         <p:with-option namet="indent" select="$my_indent"/>
>>     </p:if>
>> </p:store>
>>
>> (just like i would conditionnaly add an attribute to a element in xslt :
>> <div>
>> <xsl:if test="$class!=''">
>>    <xsl:attribute name="class" select="$class"/>
>> </xsl:if>
>> </div>
>> )
>>
>> 4) cx:eval
>> We have found very usefull to use cx:eval in our process. Actually we use
>> an XML "profile" file to drive our xproc pipeline. This file let the user
>> change parameters easily.
>> But we consider adding an xslt to an xml2epub transformation should appear
>> in this file because it's a kind of "parameter".
>> This is how it look :
>> <mode name="xml2extract.xml">
>> <parameters>
>> <param name="percent" value="9"/>
>> </parameters>
>> <steps>
>> <igs:xslt xml:base="http://localhost:777/neodev.trunk/EPUB_RES/">
>> <p:with-option xmlns:p="http://www.w3.org/ns/xproc"
>> name="store_main_result_at" select="$extract.uri"/>
>> <p:input xmlns:p="http://www.w3.org/ns/xproc" port="stylesheet">
>> <p:document href="xsl/common/modules/extract/extract_dtd_igs_v2.5.xsl"/>
>> </p:input>
>> </igs:xslt>
>> </steps>
>> </mode>
>>
>> After a bit workaround, that's really great, dynamic evaluation work fine
>> :)
>>
>> But we have made assumptions on imported xpl file of the evaluated
>> pipeline.
>>
>> For Xproc V2,  it would be nice IMHO :
>> - to have a "p:eval" (just like xsl:evaluate in xslt3)
>> - that the evaluation can be done in the context of the current xproc :
>> that means not be "oblige" to construct a whole pipeline to evaluation
>>
>> 4) syntax : variable / groups
>>
>> Last requirement is about p:variable which can't be place anywhere (even
>> with a p:pipe within the variable which make it independant)
>> We have often add p:group so we can declare a variable but p:group has
>> also "side effects"...
>> I guess there is reason for this but well we have the feeeling this is a
>> bit verbose, not to say tedious ;)
>>
>> Hope this helps
>>
>> Regards
>>
>> Matthieu
>>
>>
>>
>>
>>
>>
>> 2014-02-14 16:34 GMT+01:00 Geert J. <geert.josten@dayon.nl>:
>>
>>> Wish I were in Prague now.. alas..
>>>
>>>
>>>
>>> Added my 2c on Twitter..
>>>
>>>
>>>
>>> Have fun!
>>>
>>>
>>>
>>> Van: James Fuller [mailto:james.fuller.2007@gmail.com]
>>> Verzonden: vrijdag 14 februari 2014 12:43
>>> Aan: xproc-dev@w3.org
>>> Onderwerp: result of A&Q at XML Prague preconf day
>>>
>>>
>>>
>>> Thank you to everyone who attended ... the survey of opinion was
>>> lightweight, but a useful quick sample ... to summarise;
>>>
>>>
>>>
>>> Is XProc v2 requirements doc on the right track ?
>>>
>>> * IMHO, not enough ppl have read the requirements doc to begin answering
>>> the question reasonably
>>>
>>> * propose that folks take another look at
>>> http://www.w3.org/TR/xproc-v2-req/
>>>
>>>
>>>
>>> How XProc is being used
>>>
>>> * most ppl using XProc to replace 'duct tape' solutions.
>>>
>>> * many using it as basis for publishing
>>>
>>>
>>>
>>> Which user is most important in XProc solution
>>>
>>> * the developer implementing the solution was by far the most important
>>> user in the toolchain currently
>>>
>>>
>>>
>>> XProc
>>>
>>> * Parameters still a burning topic, looks unlikely that we could drop for
>>> v2
>>>
>>>
>>>
>>> Use Cases
>>>
>>> * JF to sit with Romain Deltour
>>>
>>> * JF to sit with Gerrit Imsieke
>>>
>>>
>>>
>>> Was suggested that DITA / XProc should be promoted
>>>
>>> * Jim Fuller will setup XProc meetup at DITA Europe (maybe George from
>>> oXygenXML can provide some advice)
>>>
>>> * XProc submissions for DITA orientated conferences
>>>
>>> * expect another mail to the list on this one following up
>>>
>>>
>>>
>>> Over XML Prague (and as ever via mailing list) Please feel free to
>>> approach any of us on the Working Group
>>>
>>>
>>>
>>> * Norm Walsh
>>>
>>> * Alex Milowski
>>>
>>> * Mohamed Zergaoui
>>>
>>> * Jim Fuller
>>>
>>>
>>>
>>> And give us your opinions, criticisms and what is important to you for
>>> XProc v2.
>>>
>>>
>>>
>>> thx, Jim Fuller
>>
>>
>>
>>
>> --
>> Matthieu Ricaud-Dussarget
>> IGS-CP - Développeur XML
>> 05 45 37 09 49
>
>

Received on Monday, 17 February 2014 15:31:27 UTC