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: default names of the catalog


At 10:03 2001 05 07 -0700, Lauren Wood wrote:
>29) default names of the catalog: we need to think about this some more.


For the record, here's what TR9401 says.

First, this is all in the section entitled "Issue B: an interchange 
packaging scheme" the initial paragraph of which is:

  The issue of interchanging a set of files among different systems
  can be partially addressed by an interchange packaging scheme that
  includes an interchange catalog that associates external identifiers
  with the various files in the interchange package. This resolution,
  which assumes the catalog format defined above, describes such a scheme.

I think it is clear that this "default catalog" was meant solely to
be used in the "interchange package" scenario, not as some sort of
"system" or "boot strap" catalog.

It goes on to say:

  To determine what file in the interchange package shall be used
  as the catalog, an application shall use the following algorithm
  (or functional equivalent):
  1.  If the document entity's s.o.i. is somehow known to the application,
      the application should first look for a storage object whose s.o.i. is
      docname.soc where "docname" is the "base name" of the document
      entity's s.o.i.  An s.o.i.'s base name is determined as follows:
      [obvious algorithm elided]
  2.  Then, look for a file whose name is "catalog".
  3.  Finally, look for a file whose name is "catalog.soc".
  [Then there is some stuff about letter case of the file name.]

The "soc" extension is for "SGML Open Catalog" which seems obsolete.

If we just reduce the algorithm to step 2, we're saying "look for
a resource whose name is 'catalog' and whose base URI is the same
as that for the document instance."

This is equivalent to having a PI of:
  <?oasis-xml-catalog catalog="catalog"?>
in the document instance.

I'm willing to say that, if and only if no oasis-xml-catalog PI is found,
then the equivalent of <?oasis-xml-catalog catalog="catalog"?> is assumed.
That way, if an author wants to avoid this behavior, they can put
  <?oasis-xml-catalog catalog=""?>
into the docuent (is there anything wrong this--the null relative URI
resolves to the current document which shouldn't be a catalog and so
should just be ignored, right?  Or we can say explicitly that a null 
value for the catalog pseudo-attribute on this PI is the same as saying
not to add any catalog to the catalog entry file list provided by the
user to the application).

Does that cover the necessary user scenarios without getting us too much
into the packaging swamp?

paul



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


Powered by eList eXpress LLC