norman.walsh.name: Comments on /2006/09/28/xprocfpwd http://norman.walsh.name/2006/09/28/xprocfpwd/comments.atom 2007-09-23T20:48:08Z Comment 1 on /2006/09/28/xprocfpwd http://norman.walsh.name/2006/09/28/xprocfpwd#comment0001 2006-09-29T06:55:40Z 2006-09-29T06:55:40Z Evan Williams 3e260f9261a6e6f01258d6c1732b4ac179f46d6f

This does indeed look quite clear. The only *slight* problem I had was with the concept of "implicit output ports". I couldn't find anything in the draft about these - but as you say, it is kinda obvious :-)

 Comment 2 on /2006/09/28/xprocfpwd http://norman.walsh.name/2006/09/28/xprocfpwd#comment0002 2006-09-29T11:43:46Z 2006-09-29T11:43:46Z Dave Pawson b46b0bd3946a0e2c96f45361a4be380edcd98ed6 http://www.dpawson.co.uk

ndw said

OK it's a pipeline step. I can see an input, I can guess what it does. I can't see an output?

then

OK a step with two inputs... yet the sourcs is 'result'? And still no output?

Then

Can you tell me what that pipeline does? I bet you can, without even reading the specification:

No, but I feel confused seeing a source called result? And no I haven't read the spec (yet :-), but having just written a 5 stage transform I think I'm going to!

Please don't remove verbosity too much Norm. It helps the less able.

regards DaveP

 Comment 3 on /2006/09/28/xprocfpwd http://norman.walsh.name/2006/09/28/xprocfpwd#comment0003 2006-09-30T09:03:18Z 2006-09-30T09:03:18Z Sean Gilligan 5a233a954bc920d83b9be766c4fafa36d235f808 http://www.msgilligan.com

In working with DocBook, I've often thought that some kind of declarative approach for specifying the pipeline, etc. was needed.

In specifying the rules for building a (large) set of output documents from a (large) set of input doucments, one problem I have wanted to solve is avoiding redundant processing when input documents have not changed.

XInclude and XSLT make this difficult to do in an Ant or Maven build file since there is no tool (that I know of) that can track whether any of the included files have changed. Currently, it seems, you can either do the entire transform each time or only run it if the "root" XML or XSLT document has changed.

I realize this would be an implementation detail/optimization but it might be worthwhile considering this possibility while working on the spec.

I remember the performance breakthrough when C language tools solved this problem and would like to see the same thing for XML/XSLT.

 Comment 4 on /2006/09/28/xprocfpwd http://norman.walsh.name/2006/09/28/xprocfpwd#comment0004 2006-11-12T12:05:54Z 2006-11-12T12:05:54Z Rastaman 4681d4ccd70005b14b639a20e9f410ec7d6b7795 http://www.ubik-products.com

I'm wondering what is different between this "new" pipeline language and the one defined previously here: http://www.w3.org/TR/xml-pipeline/ also by the W3C* but dated from 28 February 2002. Anyway it's great that there is work on this subject again, 'cause i'm actually digging into http://sxpipe.dev.java.net/ and this doesn't implement all things described in the schemas, although this is a good starting point.

* btw the schemas provided here seems to be wrong regarding the use of 2 ids attributes in the processdef element, but i guess this as already been reported in the right place.

 Comment 5 on /2006/09/28/xprocfpwd http://norman.walsh.name/2006/09/28/xprocfpwd#comment0005 2007-04-12T13:05:11Z 2007-04-12T13:05:11Z Daryn 362823d4246a110ffd74baba084a115212b74c5c

Hi, thanks for the article - but I am having troubling getting to grips with the XProc pipeline.

Could someone please go through the above XProc document and explain the details, explicitly pointing out the 'implicit output ports' ;) Kind regards

 Comment 6 on /2006/09/28/xprocfpwd http://norman.walsh.name/2006/09/28/xprocfpwd#comment0006 2007-09-23T19:50:29Z 2007-09-23T19:50:29Z benson margulies d19fe5a055bff6cceb82ec8ea87b177f10fa3e97 http://www.basistech.com

How is this whole thing different than building a few Spring POJOs and wiring them together? I haven't read the most recent draft, but the original example here sure looks like it could be implemented in 35 minutes with the Spring IoC.

 Comment 7 on /2006/09/28/xprocfpwd http://norman.walsh.name/2006/09/28/xprocfpwd#comment0007 2007-09-23T20:48:06Z 2007-09-23T20:48:06Z Norman Walsh 9f5c771a25733700b2f96af4f8e6f35c9b0ad327 http://norman.walsh.name/

You could, no doubt, implement any particular pipeline with (insert application/platform specific framework of your choice) in reasonably short order.

But XProc is language and platform neutral and reasonably declarative.

Lots and lots of folks who write XSLT stylesheets wouldn't be comfortable writing Java code to do the same translations. I expect that XProc will provide that level of interoperability and accessibility for pipelining.