minutes from ER TC teleconference 20010319

[Lauren Wood <lauren@softquad.com>]

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

No changes to the minutes from last time.

Issues document:

2) there are two questions here: are we requiring namespaces? We have 
said that things in other namespaces can be ignored, and things in no 
namespace are reserved. We are requiring namespaces; a 
non-namespace-aware processor could handle some subset of conforming 
catalogs. Do we wish to say anything about non-namespace-aware 
processors; general agreement on this.
We do require XML 1.0 + namespaces, but this is specified in the 
normative references.Nothing other than the normative references is 
normative.

3) Move to postpone. No objections to the postponement.

4) Paul says no; seconded. No objections.

5) Extensibility mechanism should be elements and attributes from 
another namespace.

6) Can an extension element change the semantics of an element from the 
catalog (non-extension) namespace: answer is no, when the question is 
sufficiently narrow. An extension attribute may change the behavior of 
the catalog, e.g., to handle both SGML and XML.We should not allow, 
.e.g, a new type of wrapper that affects the catalog elements therein. 
When a resolver is running conformantly, then it must not allow the 
presence of extraneous elements or attributes to change the behavior of 
the standard. There may be other modes where it would change the behavior.

8) postponed with number 3.

9) default value is in 9401. The spec has to be clear about default 
behaviors. In 9401, the default was implementation-defined. The 
implementation should allow the default to be set, and must say what the 
fallback default is. The editor should check whether anything in the 
spec contradicts this decision.

10) Should the nextCatalog directive be required to occur only at the 
end of the catalog: agreement on no. The nextCatalog does not inherit 
xmlbase.

11) What is the namespace name of our catalog? Move to postpone - agreed.

12) Are names in no-namespace allowed to be interpreted as catalog 
entries, or is a namespace name
   required.Answer: the former.

13) Drop this in favour of 25.

14) Should we describe a convention for representing non pubidchars in 
public identifiers. Postpone until later, as it requires interaction 
with W3C (XML Core and I18n).

15) What do we say about failures to retrieve a resource (e.g, in 
nextCatalog)? This leads to the question of whether we should have a 
processing model which includes error handling. Postponed.

16) also postponed with the rest of the delegate discussion. John has an 
opinion and will email the list to spark discussion - end of this week.

17) See issue 9.

18) postponed.

19) Editorial.These will be non-normative references.

20) Do we want to have a namespace entry type. What does it do? No; we 
have a general URI entry type. We should check that the general URI does 
do what we want for namespaces. Are there any circumstances in which we 
might want different behavior for the namespace entry type?

21) If the catalog resolver is handed a system identifier that begins 
"urn:publicid:", what should we do? Treat this as if we had been given 
the public id, and treat this as a public id if the "real" public id is 
missing. A urn is technically a system id, but can be treated as a 
public id. In other words, if no public id is supplied and the system id 
begins urn:publicid, then treat it as if the corresponding public id had 
been supplied, but no system id. Defer the issue - Paul will send email 
on this mid-week.

22) Do we want to create a TR9401 namespace to handle all of TR9401 in 
our XML catalog? John will volunteer to draft a non-normative appendix 
for this.

23) Should we assert that delegate and nextCatalog entries must point to 
other instances of XML Catalogs? Some discussion of whether XML catalogs 
must point only to other XML catalogs. Postponed the discussion.

24) Should we add a PI to point to a starting catalog set? Yes; this is, 
however, optional. This would be the logical equivalent to the 
xml-stylesheet PI. This would be a hint to the application, which could 
be overridden. This needs to be clearly explained in the spec. Tony will 
draft language for this, by the next meeting.

25) Should we add an oasis:publicLocation attribute to handle what XML 
Schemas elected not to support? One question is how many people will 
support this. John thinks it's pointless. Tony likes the idea, since he 
has an interest in schema adjuncts. Paul would like to see it, but 
recognises John's point. Normand abstains. Lauren likes the idea, since 
if we don't define something like this, no-one else will. David thinks 
it sounds superfluous. If the urn:publicid idea goes through, that will 
obviate the need for it to some extent. Defer until later. Norm has to 
resubmit the urn:publicid specification.

Ran out of time.

Lauren