override's top level default [was: minutes from ER teleconference20010108]

[Paul Grosso <pgrosso@arbortext.com>]

At 14:58 2001 01 08 -0800, Lauren Wood wrote:
>What do we call the top-level element? Norm proposes catalog. No
>objections. It has the override attribute, which implements the override
>functionality of TR 9401. We need to define what happens if this isn't
>defined in the catalog. We could make override required. This is an
>issue. We may want to go beyond 9401, which makes it
>implementation-dependent. 

Upon some reflection, I think I'd like to argue that we need to leave
the top level override value specifiable by the end user as TR9401
suggests when it says:
  An application must provide some way (e.g., a runtime argument,
  environment variable, preference switch) that allows the user
  to specify which of these modes to use in the absence of any
  occurrences of an OVERRIDE catalog entry.

One of the key ideas of catalog resolution is to be able to
refer to catalog entry files that are "out there" as well as 
those you may write yourself.  And you can't edit most catalog
entry files "out there" to change the value of the override 
attribute on the <catalog> element.  But whether you want to 
prefer the system ids or public ids in your document instance 
is something a user does want to do on a case by case basis.
In fact, at one moment I might want to use the system ids,
and another the public ids, but I can't go change the "out
there" catalog entry files (and I probably don't even want to 
have to fool with the local ones).  Instead, I just want to run
my XML application with a different runtime switch/preference
setting/whatever.  Giving a default to override makes this impossible.

paul