Tony Collen escribió:
Stefano Mazzocchi wrote:

NO! that's the beauty

echo "application/xml" > /document/@mime-type

Voila' ;-)

Actually, even better

 echo "xml" > /document/@syntax
 echo "text/xhtml" > /document/@mime-type

because MIME is getting it all wrong with this stupid +xml by mixing concerns between the syntax and the semantics.

Do you see the potential?

The obvious question is what happens when you try to do an xpath expression on a file that is not XML. Perhaps the filesystem module would know enough to check for <?xml version="1.0"?> ?



ARRRRRGGGG!



Lots of potential though :) Maybe you could tie a service to a virtual device. Like /dev/xupdate or /dev/xalan, and output to > STDOUT?



That's much better talking, bro ;-)


More RTing:

Imagine having an XSL processor in the kernel:

You could "execute" .xsl files, bypassing having to run a processor manually.

prompt$ page2html.xsl < input.xml > output.html

Borrowing the pipeline concept from Cocoon:

prompt$ cat input.xml | page2foo.xsl | foo2bar.xsl | bar2html.xsl > output.html

One could even invent files which are actually transformation pipelines -- ones which you might not be able to directly edit (or maybe be able to edit a transformation in the middle):

prompt$ make-virtual-file-pipeline virtual.xml --generator=input.xml --tranformers=page2foo.xsl;foo2html.xsl --serialize=text/xml


Itn't it kind of:


export ACCEPT="es_ES;1.0, en;0.9, *;0.1"
# more environment here
./sitemap.xmap output.html

I mean, the sitemap is like a "restricted shell" used to specify transformation chains. As HTTP is request-response, in Cocoon you give it is the sitemap, the output requested and some ENV vars ;-). With a true shell, more freedom would be needed/granted.

In any case, the material here is great for a tutorial on "cocoon for unix-geeks".

The flow is a bit different. A classic shell has the processing pipelines specification + logics mixed together, while in Cocoon these are specified as different concerns. After all, bash is a tool for programmers, while cocoon has several isolated concerns in a data processing + publishing environment.

Now you can just go

prompt$ cat virtual.xml

And get the output of the pipeline defined above, which you can then link to other pipelines, etc.

It's no wonder that this all fits in very well with what Cocoon does, since Cocoon is patterned after this concept. I'm sure if I stew on this concept enough I'll come up with more ideas and uses.

Tony



Regards
--
Santiago Gala
High Sierra Technology, S.L. (http://hisitech.com)
http://memojo.com?page=SantiagoGalaBlog




Reply via email to