W3C home > Mailing lists > Public > xproc-dev@w3.org > October 2009

Re: XSLT 2 vs XProc

From: James Fuller <james.fuller.2007@gmail.com>
Date: Tue, 27 Oct 2009 15:06:52 +0100
Message-ID: <a0ad8ffe0910270706m6d0ec527x765e00a2fd0e191e@mail.gmail.com>
To: Tony Rogers <tony@gonk.net>
Cc: XProc Dev <xproc-dev@w3.org>
XSLT is really good at transforming xml into another form of xml,
preferably in a single pass transformation ... the moment your data
(either as input or output) start looking less like XML the less
appropriate XSLT becomes (though we all ab/use it for these kind of
purposes as well).

XProc provides a facade over a suite of XML technologies (including
XSLT) effectively providing XML Pipelines which are reusable, easier
to compose and maintain, as well as being extensible.

Of course there is overlap between the two, but the further you push
XSLT away from its original intentions you will find less people able
to add or maintain or in general grok it.

XProc is focused on being more of the control loop of your program,
which is something I have found awkward with using XSLT.

W/o wanting to sound offensive, your question is somewhat trivial ...
there really is no XProc versus XSLT argument and if you use XSLT now,
its easy to use it with XProc or not.

As for arguing if you want to use XLST in place of what XProc does ...
then barring extensive FXSL usage, you will most likely have to depend
upon a specific XSLT processor own mechanism for extensibility
rendering your solution incompatible with other XSLT processors. In
this way XProc does a bit of what Apache Ant has done for java build
e.g. provide a platform independent mechanism for defining process
flow ... lets hope this works across processor as well.

The question is less of what is impossible or possible with each
technology but where architecturally each are best applied.

hth, Jim Fuller
Received on Tuesday, 27 October 2009 14:07:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:05 UTC