minutes from ER TC teleconference 20010516

[Lauren Wood <lauren@softquad.com>]

Present: David, Norm, Lauren, Tony, Normand, John

Regrets: Paul

naming catalogs: do you look for the file called catalog in the location of the 
base URI of the thing you've been handed? This makes sense. If there is no base 
URI, e.g. a stream comes in, then there could be an implementation-defined way to 
define the catalog. How could a default for that be defined? In-memory 
representations also have a problem, since there is no default. We could 
potentially say if there is no baseURI, then there cannot be a default catalog. 
SAX and JAXP both implement the resolver method by not telling the resolver the 
name of the file, so it may not be possible to determine the baseURI. However, we 
should also define what we want to happen. There are cases where the processor 
can't or won't know what the catalog is. The catalog would be used only if the 
user has not specified any catalog entries. Then the implementation should look 
for a catalog in the directory specified by the baseURI of the document, using 
xcatalog as a relative URI reference. If there is no baseURI, there can be no 
fallback catalog.

Paul's vote may no longer be applicable, since the issue has changed somewhat, and 
we are no longer asking the same question as he voted on in email.

Vote: define a fallback catalog that only applies if the user has not defined a 
catalog, and it is relative to the document's baseURI reference.

Yes: David, Lauren, Tony, Normand, John
No:
Concur: Norm

Name should be "XCatalog". No objections, except some on the casing.
Vote: XCatalog: John
xcatalog: Tony, Normand
concur: David, Norm, Lauren
Ended with "xcatalog".

Override PI: No objections to re-opening the issue on the basis of new evidence 
from yesterday's email.

Norm thinks it is a mistake and has a number of interoperability issues. It's not 
clear which part of the implementation (if pipeline) may consume the PI. It may 
need to be passed on to another part of the implementation, which would mean it 
needs to be kept.

Move to accept votes by email: accepted, no objections.

Vote: keep the PI: Normand
take it out of the spec: Paul, David, Norm, Tony, John
concur: Lauren

"urn:publicid"
always gets unwrapped to a public ID. catalog entries that specify urn:publicid 
will probably never map to anything. The output of the catalog processor will be a 
public identifier. Every other type of urn is treated as a string like other 
system ids.
Should the processor warn (the spec should say "the processor should warn"):
No: David, Norm
Concur: Lauren, Tony, Normand, John

John raises an issue: why we treat system IDs and other URIs separately.

The chair is empowered to pose this question by email on Monday. Votes due 
midnight Pacific time Monday.

The chair is empowered to pose any questions by email that seem appropriate at 
this stage.

Norm will post the updated spec by noon Eastern time on the 23rd. Vote in time to 
send it to the OASIS membership for ratification as an OASIS standard.

Lauren