Re: 8 Jan 2001 Entity Resolution Draft

[Paul Grosso <pgrosso@arbortext.com>]

At 13:30 2001 01 09 -0500, Norman Walsh wrote:
>Here is a new draft of the spec. I believe that this draft
>incorporates all of the decisions made so far.

Last part of abstract reads:
  To address these issues, this resolution defines an entity
  catalog that maps an entity's external identifier and/or name to a URI.

Since we don't appear to be including the ENTITY entry type
(or are we?), then we should delete "and/or name".

Also, since we have decided that we aren't (and shouldn't) address
what was Issue B of TR9401, I think it's time to delete mention
of it in the abstract and intro (and then delete mention of Issue A
in the intro since there is only one issue).

In fact, the abstract and intro could probably stand to be rewritten
completely in light of current events.

In the example, you show a namespace prefix on the <public> element.
What gives?  Don't tell me we have to have namespace prefixes on
every element in the catalog!  I thought namespaces were to be used
for the extension mechanism, but I see no need for them on the elements
we are defining.

In the last entry of this example, you've got a "ur" attribute instead
of "uri".

I note that we will need more examples (I realize the original TR9401
didn't have many).

I realize since this catalog is an application of XML, it "makes sense" 
to use schemas and dtds to define its syntax rather than eBNF, but geez,
that schema is quite daunting, and I'm unlikely to study it carefully
enough to tell whether it's correct or not--I guess I'll just trust you.

By the way, I note that the doctype of the schema uses a SYSTEM id
that isn't very useful for anyone (except, perhaps, Norm).  Is there
a public id for this DTD, or will everyone have to use a catalog
with a SYSTEM entry to be able to map this system id?

Just before "Additional requirements", note that "minimum literal"
is not defined in XML.  Besides, since you aren't using an EBNF
to define the language, I'm not sure you need this sentence at all.

And Additional requirement "a." about lengths of attributes can
be deleted as being irrelevant for XML.  Add. req. "c." should
be reworded or deleted--I'm not sure which--since XML Base 
normatively refers to RFC 2396 which defines base URI, so we
don't need to say what we say here.  We should probably just
say something like "conformance to this XML Catalogs spec
requires conformant support of XML Base" and add that all
values of the "uri" and "catalog" attributes must be treated
as URI references in this respect.  And I'm not sure what 
add. req. "b." adds anymore, so maybe we can get rid of
this whole section and replace it with the brief discussion
of XML Base.

I'd also delete item 6 in the following list, since this would
be covered by the earlier XML Base discussion.

In light of current events and some changed terminology, the 
following needs work:

  Generally, when a system identifier is specified in an external 
  entity declaration, it can be trusted to be a valid URI. However, in
  some circumstances (such as when the document was generated on 
  another system, when the document was generated in
  another location on the same system, or when some files referenced 
  by system identifiers have had their locations changed since
  the document was generated), the specified system identifiers may 
  not be valid. For this or other reasons, preferring the public
  identifier over the system identifier may be the preferred way of 
  accessing the entity. 

I suggest the following:

  In XML, all external identifiers for external entity declarations 
  must include a system identifier and may include a public identifier
  (production 75 of XML).  Though the system identifier is assumed to
  be "a URI reference...meant to be dereferenced to obtain input for
  the XML processor to construct the entity's replacement text" [ref.
  defn. of SystemLiteral in XML], in
  some circumstances (such as when the document was generated on 
  another system, when the document was generated in
  another location on the same system, or when some files referenced 
  by system identifiers have had their locations changed since
  the document was generated), the specified system identifiers may 
  not be the best indicators of the desired replacement text.  For 
  this or other reasons, 
  it may be desireable to prefer the public identifier over the system
  identifier in determining the entity's replacement text.

Then later, the text that currently reads:

  A public or delegate entry encountered when override is “yes”
  (corresponding to the mode where public identifiers are preferred)
  will be considered for possible matching whether or not the
  external identifier has an explicit system identifier. A public or delegate
  entry encountered when override is “no” (corresponding to the mode
  where system identifiers are preferred) will be ignored
  during lookups for which the external identifier has an
  explicit system identifier.

I'm not quite sure what to do with this.  At first I thought
it should be fixed up too, but then I realized that, when
reading a delegated-to catalog entry file, one does effectively
operate in a mode in which there is no system id.  So maybe
we need to leave this paragraph pretty much as is with a note
about the delegation processing.  I'll have to think about this.

Let's get rid of the section on hyphens or colons in the ISO 
owner identifier.

paul