- From: Jostein Austvik Jacobsen <josteinaj@gmail.com>
- Date: Tue, 15 Mar 2011 13:09:07 +0100
- To: vojtech.toman@emc.com, XProc Dev <xproc-dev@w3.org>
- Message-ID: <AANLkTikYvYqtEwUgTYAj8_sb+Wsm4mQpBS7HruYgLK+P@mail.gmail.com>
>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 > >
Received on Tuesday, 15 March 2011 12:50:09 UTC