catalogs and relative URIs [was: minutes from ER TC 20010429]

[Paul Grosso <pgrosso@arbortext.com>]

[Actually, these were minutes for 20010430.]

At 10:50 2001 04 30 -0700, Lauren Wood wrote:
>Can we resolve the override PI issue? . . .


>There will often be relative URIs in there; how are these resolved? Are 
>names in the system catalog path subject to resolution by previous catalogs? 
>No. But we do need to specify what relative URIs in the catalog are resolved 
>to. Is it the document instance itself?
>
>The system catalog path (the list of names of catalog entry files that you 
>start with) is implementation-defined; it may be where the executable is, or 
>where the File.Open dialog starts, or the fixed word "catalog", etc. Norm 
>will update the section in the spec and we will postpone the rest of the 
>discussion until then.

Here is where I got very confused and remain so.

I assume by "relative URIs in there" we mean in the "override PI" 
(by the way, "override" is a bad term to use here, since it has 
nothing to do with "override" as otherwise used in our spec).

So our first question above was:

"There will often be relative URIs in [the PI in the document instance
that adds catalog entry files to the end of the existing catalog entry
file list]; how are these resolved?"

Well, I still don't know the answer, and I don't see it in our minutes.

I think relative URIs in the prolog of the document instance (including 
those in the PI we're discussing) should be relative to the base URI of 
the document instance.

The second question above is:

"Are names in the system catalog path subject to resolution by previous 
catalogs?"

I can see the answer we give above is "No", but I don't know what a
system catalog path is.  I cannot find the phrase "system catalog"
in the latest version of the spec.  I'm not sure I understand what 
we're talking about here.  I note the minutes also say:

"The system catalog path (the list of names of catalog entry files that you 
start with) is implementation-defined; it may be where the executable is, or 
where the File.Open dialog starts, or the fixed word "catalog", etc."

This does not really help me--I don't find it clear, and insofar as I
can make any sense of it, I disagree.  What our spec says about determining 
the catalog (i.e., the list of catalog entry files--that is what a catalog 
is) is:

"Each application that uses [a catalog] must provide the user with a 
mechanism for specifying the catalog to be accessed."

That is not the same as saying that there is a system catalog (whatever
that phrase might mean) or that there is an implementation defined initial
catalog.

I don't see that we have any such concept of a system catalog,
and I don't see that we have to say anything about relative
URIs therein--that's something to be decided by the "mechanism"
by which "each application ... provide[s] the user ... for specifying 
the catalog to be accessed."

The third question above is:

"But we do need to specify what relative URIs in the catalog are resolved 
to. Is it the document instance itself?"

I do not see an answer to the question in our minutes.

Relative URIs in the list of catalog entry files (I believe this
is what we meant here, since the base URI for relative URIs within 
catalog entry files themselves are clearly discussed in the spec) 
then break down into two cases:  (1) those that got into the list 
of catalog entry files via the "mechanism for specifying the catalog 
to be accessed" for which, I've argued, we need say nothing, and 
(2) those that got into the list of catalog entry files by means 
of a nextCatalog or delegate* entry, for which I claim the answer 
is that what gets put into the catalog entry file list is an absolute 
URI that results from absolutizing the URI from the nextCatalog or 
delegate* entry whose base URI is clearly specified in our spec.

paul