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

Hmm, interesting. Thanks.

2011/3/15 David Lee <dlee@calldei.com>

> " What general purpose pipeline (XML-)languages are available?"
>
>
>
> xmlsh (www.xmlsh.org) is a general purpose pipeline (XML) language.
>
>
>
>
>
>
>
> ----------------------------------------
>
> David A. Lee
>
> dlee@calldei.com
>
> http://www.xmlsh.org
>
>
>
> *From:* xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] *On
> Behalf Of *Jostein Austvik Jacobsen
> *Sent:* Tuesday, March 15, 2011 8:09 AM
> *To:* vojtech.toman@emc.com; XProc Dev
>
> *Subject:* Re: How to add more transports/protocols to XProc?
>
>
>
> From the spec: "It is not a goal of XProc that it should be a
> general-purpose pipeline language for manipulating arbitrary, non-XML
> resources."
>
>
>
> Could XProc 2.0 be a "general purpose pipeline language"? What general
> purpose pipeline (XML-)languages are available?
>
> I like to think of XProc as a sort of XML-batch-script language, although
> that might not have been its intention...
>
>
>
> Jostein
>
>
>
> 2011/3/15 <vojtech.toman@emc.com>
>
> 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
>
>
>