minutes from ER TC 20010604

[Lauren Wood <lauren@softquad.com>]

Regrets: Paul, Tony
Present: David, Lauren, John, Norm

The spec is sometimes careless about URI or URI reference. The 
things on the RHS are always URI references.

We should postpone this topic until next week, to give Norm a 
chance to tighten up the "URI" and "URI reference" wording.

Open issue 31: circular dependencies. The same URI can return 
different results (under weird circumstances), and a different URI 
can return the same results. Circular dependencies could be 
classified as an error, with results depending on the processor. Is it 
an error to insert a catalog that has already been read, or an error 
to resolve this. If you have two catalogs, and the first delegates to 
the second, and the second delegates to the first, and neither has 
a match, then there is an error. 

What we're really saying is that it's an error to create a catalog 
chain that never terminates. It's up to the implementation to figure 
out that the chain will never terminate, and terminate it anyway. If 
there's a match somewhere it will find it, but if the problem arises 
when there is no match. 

Resolution: the editor will put the above paragraph into reasonable 
wording. No objections to this.

Paul's issues: postpone until the new version of the draft is ready 
next week.

The draft says that public IDs must be normalized. The spec also 
says that system IDs must be normalized; this may have been a 
copy and paste error. RFC 2396 defines resolution. If there are non-
ascii characters, they must be %-encoded. If there is a character 
in the attribute value that is not legal in a URI, must the catalog 
processor %-encode this? If the user types in a string that can 
never match, is that our problem? Postpone until Paul can take 
part in the discussion. John to post his response to Paul's email by 
Wednesday.

Tony's issue: If the system identifier is preferred, then the catalog 
processor will pass on the system identifier to the application. If 
the application using the catalog processor finds that nothing 
exists at the end of the system identifier, then it can come back to 
the catalog processor and ask it to resolve the public identifier, or 
do something else appropriate. So it's not up to the catalog 
processor to determine whether anything exists at the system 
identifier and then substitute something else. 

Perhaps we need a clarifying erratum in XML 1.0 to make sure we 
can put catalog processing in for system IDs. Issue to raise with 
Paul in his capacity as chair of the XML Core WG.

Conformance test suite? This should probably be another TC; 
perhaps Rob would like to form one.

Meeting closed early. Norm will have a new draft out by 
Wednesday. 




Lauren