Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


XProc: Meta-Programming and Rube Goldberg

XProc, the XML Pipeline Language, is designed as a way of describing a set of declarative processes. Learn how XProc neatly solves a number of problems that tend to transcend working with any one single XML operational language.




Full Text Search: The Key to Better Natural Language Queries for NoSQL in Node.js

eclarative programming can take a little getting used to, especially if your standard mode of operation is working with languages like Java or C#. In essence, such programming requires that you think not of objects, properties and methods but rather of rules, filters and pipelines.

Indeed, one reason that the future is looking increasingly declarative is that the web, as a network, does not lend itself well to being described as a collection of objects with methods and properties. That resistance is at least part of the reason why SOA (service oriented architecture) essentially requires that you build an entire infrastructure on top of the web just to make it work properly.

I've found, over the years, that to me a far better analogy for developing distributed web applications is to envision one of those ball and pipe machines that you see occasionally at science museums: the complex clockwork that involves moving balls around in a circuit. The balls, in general, are in one of a few different states—they are either waiting in a queue, they are hitting a filter or node, or they are moving between nodes and queues.

However, to make the analogy a little more interesting, suppose that the balls can be of different colors, each of which corresponds to a given "object," and the color of each ball can be detected and acted upon every time the ball encounters a node. What's worth noting here is that, as far as the bigger picture goes, the machine does not really care about the underlying properties of the balls; the individual filters will care, certainly, but from the standpoint of this model, the specific state of the balls beyond their color is immaterial.

In this sense, the filters themselves can be thought of in a purely functional sense as black boxes, but again at a somewhat higher level of abstraction than is normally typical for functions. In essence, at the top of each black box are zero or more queues, each of which can hold zero or more balls of a given color. Each box has a set of rules that indicates that when a set number of balls in each queue exist, then the black box will load in those balls and generate zero or more balls of a potentially different color, sending it on its way down another pipe.

Each colored ball is (typically) an XML document that satisfies a given schema. For instance, blue balls may correspond to an XHTML document, red balls would be Atom messages, yellow balls might be a data format. The cascade of such balls through the pipeline system in turn then illustrates the fact that while XML moves like messages through the system between nodes, realistically, the balls put in at the beginning of the pipeline will likely bear no relationship to the balls coming out the other side.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date