On Dec 18, Jessica P. Hekman (jessica.hekman@...) wrote:
> On Wed, 17 Dec 2003, Neil Roeth wrote:
> > Next, when I created a local catalog containing the same public identifier,
> > but specifying a different DTD, it still chose the system catalog's DTD. Is
> > that expected behavior? I.e., I thought it would stop as soon as it matched
> > the public identifier in the local catalog, but it did not, even though I am
> > sure it read the local catalog before the other one. I had to set
> > SGML_CATALOG_FILES to the local catalog to make it ignore the system catalog
> > and use just the local catalog.
> I have some memory of the *last* resolution found being the one used, but
> I could be wrong and I am too lazy to look it up. I'm not clear -- is it
> reading both catalogs? Then try reversing the order it finds them in, and
> see if things work that way. Is it only (supposed to be) reading the local
> catalog? Then there must be some bug, right?
I verified with strace that it is reading both catalogs. Reversing the order
does not matter, it still reads both catalogs and the system one takes
I found today that putting "OVERRIDE YES" in the local catalog makes its entry
take precedence. I also found that same statement in the system catalog
before the problematic entries of "DOCTYPE html ..."; that is what is making
those entries take precedence.
The OpenSP document about catalog handling says it should pick up the earliest
match. But, apparently not if the later match has OVERRIDE YES.
TR9401:1995 says that there should be two modes, one where system identifiers
are preferred, and another where they are not. In the former case, the system
identifier will always be used, in the latter, a match will be looked for
using the public identifier, entity name, and system identifier, in that
order. More specific matches take precedence over less specific matches (so a
later match could be used if it is more specific). It does not mention the
OVERRIDE keyword, but that seems to be what OpenSP uses to achieve this
The Oasis draft resolution for XML catalogs pretty much matches the semantics
of TR9401:1995. It looks like the latter was the starting point for the
This is a problem on a current Debian stable system (like Jany is running),
but not on a current Debian unstable system (like I am running). The reason
for the different behavior is due to the fact that the sequence
DOCTYPE html ....
is in the system catalog on a stable system, but not on an unstable system.
This may all be working as it should, but I'm not sure - there are a lot of
variables and interactions. Any comments about whether this all makes sense
or not would be appreciated.