Re: naming catalogs

[Lauren Wood <lauren@softquad.com>]

Norman Walsh wrote:

> / Lauren Wood <lauren@softquad.com> was heard to say:
> | The catalog resolver should, as a fallback when no other catalog is defined, 
> | look for a file named "xcatalog" (I don't really care about the name) in an 
> | implementation-defined directory
> 
> Do you really mean an implementation defined directory? You mean a
> directory (such as the directory of the base URI of the document, or
> something along those lines) defined by the standard, don't you?

I wouldn't object to that, but in our previous teleconference on the 
subject, I got the impression that putting this at the end of the line was 
preferable to most people.


> | (for example, with the document, in a 
> | directory where DTDs are commonly found, or some other choice).
> 
> Maybe you really do mean implementation defined. Ok, that's fine by
> me.  You're implementation can specify any fallback it wants, IMHO. My
> implementation looks for a 'catalogs' property in a
> CatalogManager.properties file on your CLASSPATH :-)

And you don't want other people calling it that? ;-)

> | In 
> | circumstances where files were sent using MIME, the xcatalog would be 
> | expected to be one of the files.
> 
> Uh, that's just gotta be out of scope. For the simple case of a set of
> files on a filesystem or web server, the fallback might be reasonable.
> But I think any scheme that involves packaging should leave this
> entirely up to the manifest and the package processing application.

I agree it's out of scope for us to *define* what would happen in that case, 
but I think it wouldn't be unreasonable for people to include such a file 
with such a name in their packages.


> | We want to make it easy to use catalogs; I think having a default name helps 
> | with this and I can't see the downside to it.
> 
> Here's the downside. And it's bitten me more than once in SGML systems
> using TR9401. If you say that the filename 'xcatalog' will always be
> interpreted as a catalog, it silently changes the semantics of your
> processor in ways that may not be immediately obvious.
> 
> For example, it happens that at least one stylesheet package for Jade
> ships with a 'catalog' file in the directory with one of the
> stylesheets or DTDs that specifies
> 
>   SGMLDECL '/path/to/some/standard/looking/sgml.declaration'
> 
> This works fine except that under some circumstances (I've forgotten
> exactly how to trigger this bug; I've tripped over it just
> infrequently enough not to remember the details until I've been
> debugging for 10 minutes) this makes Jade barf on XML documents
> because it interprets them with the wrong declaration.

Well, XML doesn't have SGML declarations, so we don't have that keyword. Can 
you remember having run into any other problems?

> So I'd summarize things this way:
> 
> 1. For non-naive systems, the default catalog file is
> unnecessary. They're setup using whatever methods the catalog resolver
> gives them (property files, environment variables etc.).

Which doesn't work when the XML document is sent to a naive system, or a 
non-naive system that's been set up differently.

> 2. For non-naive authors, the PI gives them a solution that will allow
> them to make things work even on naive systems.
> 
> 3. For naive systems, the default name works sometimes but when it
> fails it's much harder to explain and debug.

So what you're saying is that having an implementation-dependent default 
name for a catalog is perfectly fine, as long as the catalog specification 
doesn't mention what it might be, to make sure that more than one system 
doesn't use the same name. That would mean, for example, that neither XMetaL 
nore Epic nor XT may ever be allowed to use the name "catalogs" because your 
catalog resolver does, and so there might be some bug in usage that someone 
runs into one day. (Somewhat exaggerated, but that's how it sounds to me).

Lauren