- From: Imsieke, Gerrit, le-tex <gerrit.imsieke@le-tex.de>
- Date: Tue, 18 Feb 2014 00:43:47 +0100
- To: xproc-dev@w3.org
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
Received on Tuesday, 18 February 2014 00:05:17 UTC