minutes from ER teleconference 20010219

[Lauren Wood <lauren@softquad.com>]

Present: Norm, Tony, Paul, Lauren, John

Minutes from the last meeting accepted.

The Schemas WG does not appear to be interested in supplying public IDs for
their DTDs or schemas; the request was sent to the Schemas IG on Jan 22nd.
The Schemas WG did leave the door open to supplying a definition of how to
refer to public IDs in the schema location even though they're not
interested in doing it themselves. Some organizations use public IDs. We
should ask the Schemas WG to either define a public ID for their DTDs and
schemas, or say they won't. Norm will post to the comments list as a comment
that must be responded to [done during the meeting].

We need to define in our specification what it means for a schema processor
to be catalog-aware. We could use the URN, or a different namespace, to
define the public ID. The idea of the catalog is to pass in an external ID
and get back a s.o.i. We would need to define what happens if the external
ID is a system or public ID, and the knowledge of which is which. Suppose we
get only a system ID, and this system ID is a URN, should the catalog
processor treat this case specially? One idea is that if it's been told that
this is a system ID, then the processor should treat it as a system ID. The
other pov is that we can justify a special case for URNs. If the catalog
processor is told that something is a system ID when it's passed in, then it
determines some of what to do based on that. This needs to be added to the
issues document. 

The schema processor attempts to find a schema, and looks for a collection
of URIs. It may decide that one that starts urn: is a public ID, and others
are system IDs. It could then pass a public ID and a system ID to the
catalog processor. Or it may just choose one and throw away the others, or
anything else it chooses to do.

We can, and probably must, define what the catalog processor is handed. We
could also define a namespace for people to add a public ID to the schema,
e.g., using an attribute on the schemalocation. We could say the input to an
XML catalog is a list of URIs that contain namespace name, or system ID and
optional public ID. Or the input is 0 or more system IDs. If the XML schema
catalog has some URIs, it can pass some to the catalog processor. We need to
know what to do with those that begin with urn:. The schema processor
doesn't know what a public ID is, and passes only system IDs. There is no
requirement to have both public and system IDs; Paul wants to have both. 

We are describing a mechanism for entity resolution. There are several
possibilities for what the catalog could be handed. Perhaps not every client
(e.g., schema processors) have both system and public IDs. Perhaps one of
the calls to the catalog processor can be handed one URI, and may change
behaviour depending on whether the URI starts with urn:. Since XML Schema
doesn't have public IDs, we can't force people using XML Schemas to define
them. 

Norm will add a section to the specification to describe the API to a
resolver. This will be non-normative. Norm will also add a status section to
the spec to say that it hasn't been agreed on by the committee.

Paul was reminded to submit the comment to the XML Core WG about allowing
other characters in public IDs; this won't happen as an errata on XML 1.0
because it's too big a change. The ER TC doesn't need an official response.

Norm has posted the contents of the public ID to URN proposal to this group
for archival.

The TREX namespace name will be a public ID URN. Action item on John to
propose an FPI syntax to refer to TREX in the same way as DTDs can be
referred to. 

There will shortly be a URN for OASIS. Is there a registered owner
identifier? Norm will send email to Karl to ask on the status of this.

Lauren