Re: DOCBOOK-APPS: questions about XML catalogs?

[Paul Grosso <pgrosso at arbortext dot com>]

At 12:06 2002 11 02 -0500, Robert P. J. Day wrote:
>On Sat, 2 Nov 2002, Mark Johnson wrote:
>
>> On Saturday, November 2, Robert P. J. Day wrote:
>> > 
>> >   if one has queries about XML catalogs, where's the best
>> > place to ask?

I'm not sure of the policy of Docbook-apps.  There is a public OASIS
mailing list for catalogs.  However, Norm and I are on this list, and
we are two of the key people behind catalogs.


>i'm reading the doc on XML catalogs at OASIS, and the terminology
>is just a tad confusing.
>
>first, what's a "catalog"?  according to the doc, it's a *logical*
>structure that contains mapping information.  IOW, it's just a 
>hypothetical structure of some kind, not necessarily a file or
>collection of files, but it could consist of multiple files.
>or it could be a database of some kind.  or whatever.
>so far, so good?

Right.  The spec seems pretty clear here.

>a "catalog entry file", OTOH, is a physical document that contains
>a set of catalog entries. 

Yes, again I think the spec says this clearly.

The spec tries to use "catalog" and "catalog entry file" pretty
carefully (perhaps with the exception of the element names
themselves as you note).

> and if you look in a catalog entry file,
>apparently, the root element must be a <catalog> entry.  it seems
>that this is an unfortunate element name, since the contents
>of a catalog entry file are, technically, not a catalog.
>it seems just a bit recursive.

You are correct that we "abbreviated" some of the element names.
The element name should probably have been "catalogEntryFile", 
but we opted for the shorter "catalog" instead.

Note that the entries in a catalog-entry-file are also
catalog entries (since they are entries in the logical catalog).


>further, we read that catalog entries can be of type delegatePublic,
>delegateSystem and so on, as well as "catalog", even though all
>of the other entries (as i read it) must occur within a catalog
>element.  

I think you have a misunderstanding here, but I'm not entirely sure
what you're thinking.  Note:

  The catalog entry is the root of a catalog entry file. 
  All other entries occur within this catalog element.

Is there something else you're thinking here?

>so is a <catalog> itself a catalog entry type?

Um, sure, I guess.  It's an entry in a catalog.  I guess I'm not
sure I understand your real question.

>(side question:  does the file /etc/xml/catalog, by itself, represent
>a catalog, or just a catalog entry file?  yes, i'm being incredibly
>nitpicky.)

[I don't know if you're referring to a specific /etc/xml/catalog, but
I'm assuming not.]

It is certainly a catalog entry file.  It could certainly be a catalog.
Whether it is a catalog in a specific situation depends on what you've
told the application to use for a catalog.  Note:

  The catalog is effectively an ordered list of (one or more) catalog
  entry files. It is up to the application to determine the ordered list
  of catalog entry files to be used as the logical catalog.

>and i read that the "nextCatalog" entry does not seem to refer to
>another catalog, but another catalog entry file, which has been
>clearly defined by now to not mean the same thing.

Correct.  So I gather your issue is just the name "nextCatalog".  If 
it helps, pretend we called it nextCatalogEntryFile but are allowing 
nextCatalog as an abbreviation.


>anyway, i hope you get the idea.  i was just skimming that document
>and was just getting more and more puzzled by the terminology.
>can anyone clarify this?  or am i making too much of this?
>
>rday

Other than the element names "catalog" and "nextCatalog" themselves,
if you find a use of "catalog" versus "catalog entry file" in the
spec that seems wrong to you, please let us know.

paul