W3C home > Mailing lists > Public > xproc-dev@w3.org > March 2011

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

From: Alex Muir <alex.g.muir@gmail.com>
Date: Tue, 15 Mar 2011 11:02:30 +0000
Message-ID: <AANLkTi=u3x9wGz=xm8_G2GM=2iK9DchF6VkVqwYUTuvP@mail.gmail.com>
To: Alam Sher <alam.sher@advoss.com>
Cc: Conal Tuohy <conal.tuohy@versi.edu.au>, xproc-dev@w3.org
"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

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

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?

Received on Tuesday, 15 March 2011 11:10:17 UTC

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