Peter Flynn wrote:

> No, it's a sodding nuisance. I griped about this in extenso a 
> couple of years ago on the Cocoon list. It was obvious even 
> then that the authors had little clue about why DTDs bind to 
> documents, and that documents can be classed by their DTD for 
> distinct treatment.  It took considerable explanation even to 
> convince them that such a situation as Sebastian describes 
> could ever exist.
> 
> The upshot was that, no, you cannot do this: Cocoon 2 will 
> under no circumstances sniff at the file to see what the 
> DocType is, so the only solution is to keep different 
> document types in different directories, or identified by 
> some part of the filename.
>
> [Actually, some kind soul *did* post a solution, which did 
> involve some sneaky code to sniff at the DocType, but I 
> forget how it was done.]
 
There are a few ways this could be done, including using a JavaScript
controller to sniff the source and select a pipeline, but if you're not
using JS already in Cocoon it's a bit of an increment just for this
simple issue. 

So I think it'd be easiest to extend Cocoon to allow pipeline selection
(in the Cocoon sitemap) based on DocType. It would be a useful addition
for a lot of people I think.

Would it be enough to be able to select a pipeline based on the document
type's public id? Or is the doctype element (e.g. "TEI.2") also
relevant?

> In almost all other respects Cocoon 2 is excellent, and I use 
> it daily.
> But in this case they pulled a boner -- as also in the case 
> of failing to provide a method for invoking an external 
> binary to execute (you have to rewrite it in Java, apparently 
> -- yeah, right, rewrite nsgmls in Java so I can generate 
> ESIS...sure...)

IMHO the best way to integrate non-java software is via http. I've done
this with a Microsoft Reader eBook compiler (a Windows-only DLL that I
linked to a Windows EXE implementing a CGI interface). Closed source, so
I had no choice really.