- From: RICAUD-DUSSARGET Matthieu <matthieu.ricaud@igs-cp.fr>
- Date: Tue, 18 Feb 2014 10:50:45 +0100
- To: XProc Dev <xproc-dev@w3.org>, COURT Axel <axel.court@igs-cp.fr>, GELINAUD Fabrice <fabrice.gelinaud@igs-cp.fr>
- Message-ID: <CADRkOwGbuM+MB2NbT8-7_PQnA2n+L0HqDh2y7oYhG=o=Gzqhag@mail.gmail.com>
Hi Gerrit, Yes I was in Prague this year, but I could not be there on Friday so I unfortunately missed your presentation on le-tex :( We have just met on the last day outside speaking about your TEI editor presentation on the demo jam. By the way, in our project, we did not (for the moment) need a "cascading resolution" for xsl import in cx:eval because all our imports are URL. These url are configured from a localhost web server (WebServerZaurus) for which we have defined aliases to point to the good path of the developper's SVN working copy. When deploying the application (with ANT) we can easily replace this aliases by the good relative uri. Anyway from what I read on Le-Tex, it seems to be really near to what we do in my company. I think it's a good idea to keep in touch ! I copy this mail to my collegues : COURT Axel <axel.court@igs-cp.fr> GELINAUD Fabrice <fabrice.gelinaud@igs-cp.fr> Regards, Matthieu 2014-02-18 0:43 GMT+01:00 Imsieke, Gerrit, le-tex <gerrit.imsieke@le-tex.de> : > Matthieu, > > I assume that you have not been to Prague recently, because what you > described (dynamic evaluation of xpl, the file formats involved, …) much > resembles what I presented on Friday, and we didn’t meet afterwards. Please > have a look (if you hadn’t done already) at my slides [1] and at transpect > [2] (as poorly documented as it stands now). > > I’d like to keep in touch with you or your colleagues/successors as to > further developing standard pipelines for publishing but also for > documenting use cases for a standardized p:eval or even for an XSLT-ish > p:import variant. For the time being, we reduced the latter problem to > cx:eval + xsl:import: from a list of possible pipelines (configuration > cascade), load the most specific and then evaluate it [3,4]. But if there > is no .xpl at a certain location, don’t look for the next location in the > cascade. Instead, look whether there’s an .xpl.xsl file before continuing > on the cascade. The .xpl.xsl, if present, must implement a template called > 'main' that usually loads another .xpl file and adds/changes/removes some > steps. This .*.xsl mechanism is not limited to .xpl.xsl, btw. > > Gerrit > > [1] http://publishinggeekly.com/wp-content/uploads/2014/02/ > XMLPrague/transpect/ > [2] http://www.le-tex.de/en/transpect.html#transpect-modules > [3] http://publishinggeekly.com/wp-content/uploads/2014/02/ > XMLPrague/transpect/#/6/3 > [4] https://subversion.le-tex.de/common/pubcoach/trunk/xpl/ > load-cascaded.xpl > > > On 17.02.2014 16:28, RICAUD-DUSSARGET Matthieu wrote: > >> 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 >> <mailto: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 <mailto: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 >> <mailto: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 >> <mailto:james.fuller.2007@gmail.com>] >> *Verzonden:* vrijdag 14 februari 2014 12:43 >> *Aan:* xproc-dev@w3.org <mailto: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 <tel:05%2045%2037%2009%2049> >> >> >> >> >> >> >> -- >> Matthieu Ricaud-Dussarget >> IGS-CP - Développeur XML >> 05 45 37 09 49 >> > > -- > 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, Dr. Reinhard Vöckler > > -- Matthieu Ricaud-Dussarget IGS-CP - Développeur XML 05 45 37 09 49
Received on Tuesday, 18 February 2014 09:51:44 UTC