Re: New draft published: 27 Apr 2001

[Paul Grosso <pgrosso@arbortext.com>]

At 14:47 2001 04 27 -0400, Norman Walsh wrote:
>I've put a new draft of the spec online at
>http://www.oasis-open.org/committees/entity/spec-2001-04-27.html


  The catalog can be used in two different, independent ways: 
  (1) it can be used to lookup the replacement text for an external 
  entity, . . .

s/lookup/locate/ or something.  The catalog does not provide the
replacement text, it provides the location of the replacement text.

  The nextCatalog entry can be used to insert new catalog entry files...

s/new catalog entry files/a new catalog entry file/
(a single nextCatalog entry can only insert one).

  The input to a resolver, such as the SAX entityResolver(), that 
  locates external identifiers is a system identifier and optionally
  a public identifier. 

Suggest you change the commas to emdashes (otherwise, it's tempting
to parse "that locates" as modifying "SAX entityResolver()" on first pass).

  The delegateURI entry indicates that URIs that starts with the specified...

s/starts/start/

  The initial search strategy in force at the beginning of each catalog 
  entry file depends on the preference as determined by the application 
  (possibly under user control).

  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
  occurrence of the override attribute on the catalog entry. 

The parenthetical phrase in the first part above implies that the
initial search strategy MAY be under user control, but then the next
sentence implies it MUST be under user control.  (I realize this
language came from TR9401.!)  

  General:  Why do we have all uppercase URI in delegateURI but
we have all lowercase uri for the uri entry type?

   In addition, unqualified attributes, other than the attributes
   explicitly described in this Specification, are reserved for future use.

Do we mean just unqualified attrs on elements within our namespace,
or all unqualified attrs even when in the starttag of an element
in another namespace?  (I think we should mean the former, in which
case we need to reword that above quoted statement.)

Also, if a namespaced element in another namespace is ignored, then
its content could contain an element in our namespace and it would
be ignored too, right?  Need we make this clear?

  Search through the document for "opne"; there are two occurrences,
and both should be changed to "open".

I see you've decided to do systemid delegation before publicid matching.
Since delegation is sort of saying "I don't have a match in this catalog
entry file, so try elsewhere", I could see an argument for doing publicid
matching before systemid delegation.  Could you outline the pros and cons
of each, preferably giving some user scenarios that would support one or
the other order?

In the External Identifier Resolution algorithm, I question whether
step 8&9 are correct.  I don't see the catalog lookup process as 
returning the originally given system id, I see it as returning one
of the right hand sides from the catalog or "no match".  It is up to
the calling application to decide what to do with "no match".  In the
case that there was an original system id, it would presumably use it,
but that's not for us to say.  And in the case that there was no original
system id, it's not necessarily an error--it's just that this catalog
lookup failed to find a match.  Quoting from our own introducation:

  This specification does not dictate when an entity manager should
  access this catalog; for example, an application may attempt other
  mapping algorithms before or (if the catalog fails to produce a
  successful mapping) after accessing this catalog.

I'd like to see step 8 and 9 replaced by a single step that says
something like "Indicate to the calling application that no match was found."

Under URI Resolution, step 1, s/catalog file/catalog entry file/.

Under URI Resolution, the 6 step algorithm, as I discuss above, 
replace step 6 with "Indicate to the calling application that no
match was found."

  XML Catalogs support this feature with a processing instruction,
  “<?oasis-xml-catalog>”, which allows a document ...

No they don't.  That PI is not in the catalog, and is not supported
by XML Catalogs.  It has to be supported by XML parsers that support
XML Catalogs.  The best we can do is say that "This resolution suggests
that XML parsers incorporating XML Catalog support recognize such PIs 
to allow a document...."  (I'm still not convinced we want to do this.)

  The <?oasis-xml-catalog> processing instruction must appear in the prologue.

That means it could appear in the middle of the internal subset.  I
thought we said it had to appear before the doctype decl, if any.
(And if we do that, that obviates the need for the second bullet.)

  The URI that identifies the catalog file might not be subject...

s/catalog file/catalog entry file/

paul