Re: XProc or not XProc?

XProc the specification provides greater benefits than just chaining
transformations together. At any rate, your example answers your
question, you found yourself having to write an extension function to
do desired functionality, desired functionality that others have
obviously desired through the years as they have designed extension
functions to achieve them or just complained that they weren't
available, or implemented it in other non-extension function ways,
this indicates that the desired functionality should be standardized
so that everyone can easily do it in the future without duplicating
work. Perhaps it should be standardized with some other attendant
functionalities that relate together. hence XProc.

Cheers,
Bryan Rasmussen

On Sat, Jun 28, 2008 at 6:38 PM, Vladimir Nesterovsky
<vladimir@xxxxxxxxxxxxxxxxxxxx> wrote:
> Hello!
>
> In the project I'm working on, I've found myself performing tasks XProc was
> designed for.
> Namely perfroming a series of transformations, according to a configuration,
> with massive input, and output, and with error handling.
>
> To achieve a desired effect I had to create a set of extension function.
>
> And now, I have questions:
>
> Is XProc so really required?
>
> Why should XProc be designed rather than extending (providing new api for)
> xslt/xquery to perform pipeline processing?
>
> Are xslt/xquery less declarative than XProc?
>
> I wouldn't probably asked such questions if XProc were already well
> established with implementations available.
>
> --
> Vladimir Nesterovsky