cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Cocoon Blocks
Date Wed, 03 Jul 2002 08:49:22 GMT
"J.Pietschmann" wrote:
> Stefano Mazzocchi wrote:
> > Good point.
> >
> > +1 for block.xinfo
> >
> Hmm. Beyond .xml, .xsl, . xhtml and .fo there ought to
> be .xconf, .xmap, .xtarget (yuck!) and now .xinfo
> extensions associated with the XML edit mode.
> It's getting out of hand.
> What's wrong with sitemap.xml and blockinfo.xml?

Hmmm, that's a pretty good point, I might say.

> Rationale
> - there is only one web application description file
>    in a context, and Sun choose web.xml.
> - there is usually only one build description file
>    in a context, and Ant uses build.xml. Even though
>    multiple build description files could be put into
>    the same directory, the usual scope is a "project",
>    and "projects" tend to have their own directory
>    subtree.
> - there is only one sitemap in one context. Even though
>    multiple sitemaps could be put into the same
>    directory, subsitemaps tend to have their own
>    directory  subtree. The situation is quite similar
>    to the Ant build description files.
> - there should only be one block info in one context
>    (the block). Unless I got something very wrong, the
>    situation is quite to the web.xml situation.
> The .xconf is ok:
> - there can be more than one configuration file in
>   one context (cocoon, logkit, fop)
> - multiple .xcconf files may be in the same directory
> - cocoon.xconf is more informative than cocoon.xml,
>   and easier to handle that cocoon-config.xml
> Caveat: the extension doesn't say anything about the
> XML schema used, cocoon.xconf likely needs an other
> DTD than logkit.xconf.

You say that the extension doesn't say anything about the XML Schema
used. Well, this is not really the case. Examples are 


Now, the point is: having extension-triggered behavior is a *huge*
design mistake that some operating systems do (windows, first of all,
but also some UNIX desktop do the same mistake): the name of the file
should *not* indicate anything about the *nature* of the file. It should
be stored either inside (as for UNIX scripts with #!/bin/sh) or
elsewhere (as in MacOS, somewhere on in the file system FAT)

XML files have the ability to identify themselves precisely, so, in
theory, we should *not* need any special extensions for XML (or just use
.xml to indicate that xml is the syntax used).

Unfortunately, we don't live in a perfect world.

So, I agree that well-formed XML files should *not* include any special
extensions.... but valid XML files, which have such a special semantics
that special editing tools might be required for them, should.

Using this simple design pattern, I agree that 'block.xinfo' doesn't
really need an extension different from .xml

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message