Testing times ahead...

Yeah, I know, I've used that corny title before but I do need to spend some time testing my XProc pipeline representation generator. I hesitate to call it a pipeline renderer because to my mind that conjures-up thoughts of Pixar's RenderMan 3D graphics pipeline architecture and that's something completely different. Although I did work on an SVG renderer called X-Reyes using the Reyes architecture that RenderMan is based upon, and, yes, I wrote it in XSLT. Well I would wouldn't I ;-)

So, as for testing the SVG representations, it strikes me that, amongst other sources, the XProc Test Suite will be a fertile ground for a wide variety of pipelines. In saying that though there are rather a lot of tests and I'll have to filter-out the ones that are designed to generate errors. At present my XProc parser isn't designed to flag errors in XProc documents, but that's not to say it couldn't.

Whilst Presentation is Important, Timing is... Everything!

While I'm currently attempting to come up with a simple, appealing and effective way of presenting an XProc pipeline's steps, and the connections between them, I find myself reminded of the old adage that 20% of the effort gets you 80% of the result. The 80/20 rule, or the Pareto Principle, is touted by many people as a way of achieving the most in the smallest amount of time/effort but in reality it's about 'getting away' with not finishing things off properly. Anyone who's worked on presentation of information and/or GUI design will attest to the fact that 20% of the effort leaves you with err..., well, 80% of the job still left to do.

Now, of course, as I'm up to my neck in XProc, XSLT, SVG and SMIL you can bet your bottom dollar that I'm in my happy place. However, despite being surrounded by my favourite technologies, the work does raise many issues around laying-out connected objects and routing those connections with the minimum of ambiguity...

Ahhh, now where did I put my Edward Tufte collection.

Once the presentation has been sorted I'll be turning my attention to the even more exciting challenge of animation and timing.

Parse Part Two

After earlier attempts at parsing XProc pipelines in my 'half-pipe' project I've learnt a thing or two about what constitutes augmenting a pipeline so that you can carry-out further processing. This time round I'm merging the source pipeline with the XProc step declarations (lifted from the 'Pipeline Step Summary' in the spec.) in order to generate a pipeline that states not only the ports that I'm declaring but also the implied ones too. By 'implied' I mean those that you don't have to declare in order for the pipeline to work. You don't need to declare the input source unless you are either explicitly binding it yourself or adding a select attribute to it.

I've also included the output ports too but an XProc processor will 'spit out its dummy' if you declare them in an instance of a step. So to get around that I've embedded them in a p:pipeinfo so that the processor will ignore them but I can still use them. Above all else, I want to ensure that once I've finished parsing and augmenting a pipeline that it will still function as one before I then try and render it as SVG.

XProc + XSLT + SVG + SMIL = Fun

About a year ago (15th September 2009) I blogged about this idea of orchestrating XProc pipeline steps using SMIL Timesheets. I'm sad to say that I've done nothing with the idea between then and now. I'd hoped to present a paper on the subject at XML Prague 2010 but, for one reason or another, that didn't come to pass, and yet I've found myself drawn back to it from time-to-time. However, this time in back with a vengence.

Yes, a combination of needing to try-out IE 9's support for SVG, yep, that's right, native support for SVG in Internet Explorer. Whatever next - XForms in IE? One can but dream. I've also been wanting to do some more SVG (I haven't for a long time) and I just feeling the need to get my hands dirty with some full-on XSLT and XProc.

So, to that end, I've started work on some transforms that will generate SVG representations of XProc pipelines, and once I've got that in some reasonable shape I'll then use a bit o' SMIL to animate the execution flow of said pipelines. Finally, all being well, I'll be interpreting the Timesheets that orchestrate the step execution to present a view of a XProc+Time pipeline.

Rather than the usual over burdened transforms, I'll be splitting out the various parsing, interpreting and rendering processes as discrete transforms that are themselves invoked from an XProc pipeline.

The idea is to 'prototype' the orchestration of SMIL controlled pipelines using SMIL. Its kind of self-supporting, isn't it.

XProc and SMIL: Orchestrating Pipelines

Although the W3C's XML Pipeline Language (XProc) hasn't even left the stable yet, people are already looking beyond its original purpose. XProc was designed to solve the problem of how to describe the joining together of multiple XML processing steps. So, the question is, how do you extend XProc to handle new features like explicit concurrency...

 XProc and SMIL: Orchestrating Pipelines