Understanding XML: Moving through the Pipeline
[UPDATE: If you consider the idea that this could quite easily become an "extension specification" to the XSLT 2.0 spec or, in essence, taking this exact proposal and reediting it to take only the proposed p namespaced elements that do not exist in the xsl namespace and explaining the general idea behind how this would/could work I would bet that you could see this proposal reach reccomendation in record time, quite possibly even at or around the same time as XSLT 2.0, XPath 2.0, and XQuery 1.0 get the golden stamp of approval if you consider that its about this time next year that most people have mentally placed the final rec hittin' the bitwaves' for these three beasts of burden.]
[ORIGINAL POST]
I've seen both the original announcement and several posts as follow-up, including this one from Kurt. Just to play Devil's Advocate I thought I would propose the following question:
With as rediculously close as this specification is to XSLT why not just... wait, before you fill in the blanks here I wasn't planning on continuing with "use XSLT" -- instead what I've been thinking about (and am using as we speak as I continue work on the ChannelXML/WWWebTop project -- second iteration of possible additions to the yet-to-be-release LispML project) is actually allowing dynamically created pipelining that is directly embedded in the transformation, enclosing the end-user output in a "sequenced pipeline shell" of sorts that is namespaced (of course! :) and is processed by the specified process for each pipeline sequence contained in the output of the transformation.
For example...
Lets say I want to dynamically create a "pre-cache" of the next five posts to my blog such that I can then tell the client upon receiving the http stream to create 5 new DOM objects and store within these the content of the five pre-cached entries(note: in thinking through this particular thought I realized about 10 better ways to invoke this particular example, but I'll stick with it with the disclaimer that this isnt necessarily the perfect use case.) These could very easily be represented by a reference to an atom feed so in reality theres no actual content being sent with the stream, and instead just a namespaced sequence that tells the browser that once the document is loaded to then using XMLHTTP [Given that in this particular case we would be accessing and XML data feed I guess it would be more accurate and appropriate to use the document function via XSLT, loading the result of the transform into the DOM object, now wouldn't it :D] to access a particular atom feed and cache the contents to give the impression of an even faster load time. The actual stream received my look like:
[Please Note: If reading this from the front page you will probably not see any code in the box below. Please access the actual content page for this post to view the sample]
---
HTTP HEADER STUFF
<html>
<head>
<title>foo</title>
<script src="pipeline.js" type"javascript"></script>
<p:preCacheDOM src="nextFive.xml">
<script type="javascript">
<p:for-each select="document(parent::*/@src)/atom:feed/atom:entry">
<!-- Wow! I really need to pay attention when writing sample code that is at least is somewhat accurate! Before this update this read "select="parent::*/@src/atom:feed/atom:entry"" which would obviously be worthless, returning an empty node-set instead of the document we are in desire of. Actually, the way its written at the moment wouldnt really work either unless the embedded stylesheet was run over the top of itself, which is possible but not the in the format it currently exists in. I'll assume you get the point and not worry about the obvious fact that this wouldnt work in it current state... -->
<p:variable name="id" select="atom:id"/>
var <p:value-of select="$id"/> = new DOMDocument();
<p:value-of select="$id"/>.Load(atom:link/@href);
</p:for-each>
</script>
</p:preCacheDOM>
<script type="javascript">
processPipeline();
</script>
</head>
<body>
...
</body>
</html>
---
From a client side browser app this would become even more compelling for dynamicaly generated data that is to be used as part of an XForms application, for example. In reality the "p" namespace could just as easily have been "xsl" and could have been invoked either by client-side XSLT or a call back to the server via XMLHTTP, whichever is appropriate based on the client browser.
But obviously the client is only a piece of where this concept could be applied. But whether invoked via a client side process or on the server which then continues the pipeline until there are no more "p" namespaced sequences in the output to process, either way its of no great concern. As long as the ability exists to process the embedded pipeline sequence then I cant foresee anything that would keep this concept from simply working.
The greatest benefit that I can see (beyond the obvious) is that this would allow for a completely dynamic specification that would give room for growth as new processing sequences or pipeline processing applications are developed. It would be easy enough to take an AspectXML approach to this that, in essence, would correctly embed a processing sequence based on the particular platform or transformation engine or ... As long as there exists a definition file that properly maps the correct aspects to the processing sequence in question (or, if left out, the correct logic put into place to allow for a default sequence, or no sequence at all, etc...) then type of system could become really quite powerful and useful...
Anyway, just a random thought that I thought I would throw out there (with personal backing to the idea that this methodology of XSLT processing (2.0) works and works quite well) just to see what the rest of you might think or might have to add to this. It just seems to me if the effort is going to be made to get a pipelineing specification in place then maybe all possible avenues should be considered before putting in all that work only to find that, in 2-3 years when final recommendation is reached, nobody really cares anymore....
TrackBack URL for this entry:
http://www.xsltblog.com/xslt-blog-mt/mt-tb.cgi/768