minutes from ER TC teleconference 20010507

[Lauren Wood <lauren@softquad.com>]

Regrets: Tony, Normand

Present: Norm, Paul, Lauren, John

Minutes from the last meeting accepted.

1) vote on our apparent consensus on the public ID to URN mapping, which is
documented at
http://lists.oasis-open.org/archives/entity-resolution/200105/msg00017.html 
with the exception that the inital "+"  in FPIs should also be encoded.

Unanimous consent.

2) does everyone agree that the URNs that Karl assigned are reasonable?

Tony (in email) wanted version numbers on the namespaces; not everyone is 
comfortable with this. You may need versioning if there's an incompatible 
change. A catalog may object to something that's not in our 1.0 
recommendation. Processors may reject a catalog based on the new entry; you 
don't really want the provessor to reject the entire list of catalogs. You 
probably don't need a versioned namespace for every version. Perhaps 
processors should be made to silently ignore everything they don't 
understand, which would mean that new elements and attribute can be made for 
incompatible changes to the catalog syntax and we won't need explicit 
versioning now. We don't want old processors to reject new catalogs when in 
fact they may understand most of them. We would never be able to add new 
elements or attributes that could change existing elements or attributes. 
New things need to have new names; old processors will ignore them and new 
processors will process them. If we need really large changes, we can change 
the namespace name. Question: if the element is ignored by the catalog 
processor, is the content also ignored? Yes. People on the call are happy 
with the unversioned URN and don't see the need for versioning.

3) catalogs and relative URIs - see thread starting
http://lists.oasis-open.org/archives/entity-resolution/200104/msg00040.html

Question: There will often be relative URIs in [the PI in the document 
instance that adds catalog entry files to the end of the existing catalog 
entry file list]; how are these resolved?
Answer: They are relative to the base URI of the document instance. The PI 
has to be in the document instance, and occur before the doctype declaration 
in the prolog.

Question: what is the system catalog path? Get rid of the term, even in our 
discussions, since it's confusing.

Each application may have a default catalog, or a way for the user to set 
the default catalog. A relative URI within a catalog is relative to the 
current base URI. The nextCatalog entry type is relative to the current base 
URI, which is set by xml:base, or the base URI of the catalog. The RHS of 
catalog entries are not themselves subject to catalog resolution.

4) issue 21: I don't think the email we've seen covers the issues related to 
issue 21; Norm and John had the action item to send email about what the 
catalog resolver should actually do when handed a urn:publicid system 
identifier.  - This issue needs more discussion in email.

23) Should we assert that delegate and nextCatalog entries must point to 
other instances of XML Catalogs? Is it an error for delegate and nextCatalog 
to point to resources that are not XML Catalogs?

Norm believes that we should not stop people pointing at other types of 
files (e.g., TR 9401 catalogs), but if the processor doesn't know what to do 
with them, it should act as if it couldn't find the resource (which is 
answered by issue 15). Unanimous agreement on this position.

25) Should we add an oasis:publicLocation attribute to handle what XML 
Schemas elected not to support? Postpone until we resolve issue 21.

26) Do we need a version attribute? What is our versioning strategy? - 
Proposed to not have one; see discussion earlier in these minutes.

27) Is the 'override' attribute poorly named. Would another name like 
'prefer' with the values 'system' and 'public' be clearer?
Unanimous agreement.

29) default names of the catalog: we need to think about this some more.

Lauren