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.]
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
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
> 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
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.