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

Hi Jakob,

I don't know when is the conference you mentionned, but I will soon leave
the company I'm working in, so I guess it won't be easy to make a
presentation of our process migration (but I can tell about this to my
collegue and direction maybe).

By the way, for what I can say :

- We are performing conversions for our client in books edition : xml2epub,
word2epub, indesign2epub, xml2xml (client format), workflow word2epub with
schematron control on flat XML before conversion, xml2xml.extract (ex : 9%
of the corpus but never cut a sentence that finish with ":", according to
client rules); epub2, epub3, pdf2fixed layout epub with svg etc., etc.

- At the begining we made a perl script to drive xml2epub tranformation
only. An xml profile file permits user to change a few parameters and even
add xslt transformation in this process. But this was really strenght
constraint, it works for only one subprocess with a number of options
really predefined. This need has become bigger with the time and we needed
more flexibility.

- So (with the few time wa had inbetween production work), we opened this a
bit by making an ugly mixture of "perl, xproc, batch and xslt...". It works
for a time a permit us to reach our everydays need but so ugly hard to
maintain etc.

- For about 2 month we have considered migrating to a robust and generic
way of lauching our transformation, with a minimum of assumptions. This has
lead to interesting braim storming where ANT and XPROC came up as
concurrent (or maybe complementary solutions).

- After testing xproc more deep, after struggleling a bit we finaly decide
to use xproc. One of the big deal was to say "hey what about having an
xproc file to replace our xml profile file" ? We did it finaly by cheating
a little bit : the xproc file imports a driver.xpl and some common
functions. There's is only one step in the profile which is an inline xml,
which contains some xproc step to be evaluated... Well a bit complicated
but, we have fixe the rule of use of our xproc mechanism and we are happy
with it.

- We use ANT to deploy this "Xproc driver" (which is plugged to SVN and
localhost uri served by and tiny web server for developpers)

If you want to discuss more about this experience don't hesitate to contact
me on private.

Regards
Matthieu



2014-02-17 15:46 GMT+01:00 Jakob Fix <jakob.fix@gmail.com>:

> 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
>>
>
>


-- 
Matthieu Ricaud-Dussarget
IGS-CP - Développeur XML
05 45 37 09 49