Some suggesttions for XProc
by Rick Jelliffe
The new draft of XProc is out and has fewer spangles. Here's a post I sent to their suggestion box.
|M. David Peterson
I agree with your point regarding "port". Too confusing.
In regards to streams, zip files, etc... Wouldn't it make more sense to use a format that has specifically been built around collections of data files -- e.g. Atom? The additional benefit of being able to attach the Atom specific meta-data to each entry allows nicely for things like versioning, comments (without actually having to use XML comments, and instead the built in 'summary' element) and keeping track of things like when the collection was last processed using the 'updated' element as well as when a collection was first made available using the 'published' element such these same pipelines for data processing can easily be queried to determine how old the data is, comparing this to other versions of the same Atom file to determine which is the newest, etc... etc... etc...
Adding to this a bit, its simple enough to add a more compact version (such as that in which you have outlined above) inside of the 'content' element, so in other words, this is the kind of thing that would allow nicely as an envelope for a pipeline input/output sequence.
Just food for thought...
I do agree with you about accepting different formats as inputs and outputs. We just have to define an XML notation for each.
I am not using Xproc personnally because I have already designed my own dialect to perform quite the same operations but with a tree approach. For example, I use to save a sub-tree of elements which could have been generated by a transformation of another sub-tree using ...
What we need is a simple way to describe ordinary operations in XML.