"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
.xsd
.xslt
.xsl
.svg
.xmap
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.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
