OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: naming catalogs


/ 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?

| (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 :-)

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

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

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

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.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM   | To enjoy yourself and make others enjoy
XML Standards Engineer | themselves, without harming yourself or any
Technology Dev. Group  | other; that, to my mind, is the whole of
Sun Microsystems, Inc. | ethics.--Chamfort


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC