RE: How to add more transports/protocols to XProc?

I think I should maybe describe my own personal perspective when it comes to XProc. In my view, XProc is first and foremost an XML processing language in the same family as XSLT and XQuery. I like to think of an XProc pipeline as an XSLT stylesheet on steroids if you will: you have some input data and you have a recipe of how to process/transform it. That is the main thing for me.

Then you have the additional features of XProc. For instance, the extensibility mechanism that allows you to very naturally integrate with all sorts of external tools and include them in the processing pipeline. This is a very nice feature, which, when used correctly and *judiciously*, can be of great benefit.

Personally, I wouldn't recommend using XProc as some kind of enterprise middle-ware component, for the same reasons that I wouldn't recommend using XSLT for this.

Just my two cents.

Vojtech


--
Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
vojtech.toman@emc.com
http://developer.emc.com/xmltech

From: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] On Behalf Of Alex Muir
Sent: Tuesday, March 15, 2011 12:03 PM
To: Alam Sher
Cc: Conal Tuohy; xproc-dev@w3.org
Subject: Re: How to add more transports/protocols to XProc?

"There is no persistence context in XProc either, consider a scenario where I could serialize the state of a pipeline and invoke it after a  long running task would have finished, may be raise an event and a pipeline step could have been registered to listen to a special 'Event (Event ID)' port for later invocation?"
--
Bunch of question comes to mind if anyone has some time...

A. What are the priorities of XProc?


B. Given a company that sucks in a lot of data, standardizes it in XML, manipulates it in various departments, and spits it as a product on various outputs. What should the following list look like if adjusted to be accurate?

1. Communication
2. Streaming -- or perhaps better to say fast and efficient
3. Extensibility
4. Bunch of easier to implement stuff?

C. Would a data storage-in-memory-communication system (SIMC)  which sends messages, to whatever is listening, that a new file of some id/class has been put/get data and queried as to what data is available with the option of saving files not used much to a solid state disk/db be useful tool for xproc?

D. Would an XProc designed to be used solely with a SIMC simplify the language, why or why not?

E. Would communication be greatly simplified as you could store any data or message on this SIMC and easily access it asynchronously?

F. What is the most simple way to handle the most complex Xproc?

Regards
Alex