XML Catalog Issues Document

Working Draft 23 May 2001

This version:
Revision 1.4: 23 May 2001
Previous versions:
Revision 1.3: 23 May 2001
Revision 1.2: 17 May 2001
Revision 1.1: 07 May 2001
Revision 1.0: 30 Apr 2001
Revision 0.8: 27 Apr 2001
Revision 0.7: 02 Apr 2001
Revision 0.6: 13 Mar 2001
Revision 0.5: 31 Jan 2001
Revision 0.4: 22 Jan 2001
Revision 0.3: 8 Jan 2001
Revision 0.2: 11 Dec 2000
First draft 0.1: 27 Nov 2000
Norman Walsh <Norman.Walsh@Sun.COM>

This document tracks open issues in the OASIS Entity Resolution Technical Committee.

Open Issues (1)

How should a catalog processor behave if it encounters a circular dependency, e.g. firstcatalog.cat contains a <delegatePublic> pointing to secondcatalog.cat which in turn contains a <nextCatalog> pointing back to firstcatalog.cat? Should it simply ignore the reference, or should it report an error?

Resolved Issues (30)

Which schema language is normative?

Resolved: 22 Jan 2001. Prose is normative, schemas provided are informative.

Should our requirements state explicitly that we require XML 1.0 + Namespaces? (As opposed to the more vague statement "XML" from which someone might conclude that XML Schemas or RELAX or XInclude or some other specification was relevant.)
What do we do about delegate? Do we need to have a delegate for public identifiers, a delegate for system identifiers, etc. This is the functional class versus syntax issue again. URNs where?
Do we want to allow the catalog to map entity names to URIs?

Resolved: 19 Mar 2001. No.

What is the extensibility mechanism? Elements from another namespace?

Resolved: 19 Mar 2001. Elements and attributes from other namespaces.

Can an extension element change the semantics of an element from the catalog (non-extension) namespace.

Resolved: No.

The TR9401 BASE declaration had a scope that we've lost in the transition to xml:base. We could attack this problem by allowing the root element to be recursive. We could also attack this by adding a distinct grouping element.

Resolved: XML Catalogs have a group element for this purpose.

Do we want to allow delegation based on system identifiers (in addition to public identifiers). See the semantics thread.
Should the override attribute on catalog have a default value or be required?

Resolved: 19 Mar 2001. No. The implementation should allow the default to be set, and must say what the fallback default is.

Should the nextCatalog directive be required to occur only at the end of the catalog.

Resolved: 19 Mar 2001. No.

What is the namespace name of our catalog?

Resolved: 30 Apr 2001. Norm will contact OASIS to get an OASIS URN.

Are names in no-namespace allowed to be interpreted as catalog entries, or is a namespace name required.

Resolved: 19 Mar 2001. Names in no namespace may be interpreted as catalog entries.

Resolved (again): No, names must be in our namespace to be interpreted as catalog entries.

Public identifiers for schema locations.

Resolved: 19 Mar 2001. Dropped. See issue 25.

Should we describe a convention for representing non pubidchars in public identifiers. And what should that convention be? (Perhaps %-escaping)

Resolved: 30 Apr 2001. No.

What do we say about failures to retrieve a resource (e.g, in nextCatalog).

Resolved: 30 Apr 2001. Must recover by ignoring the failed catalog and proceed; may issue a warning to the user.

In XML, every external identifier has a system identifier (it may also have a public identifier). Delegate processing, as currently defined, would effectively discard the system identifier for processing the delegated-to catalog. This may not be the right thing in XML.

Resolved: 19 Mar 2001. We must preserve this symantic.

What is the default for override. TR9401 specifies that it must be a runtime user-definable option so that catalog interpretation can be changed on the fly. If we specify a default, or require the attribute, we will lose this functionality.

Resolved: there is no default.

If we define delegation of system identifiers analagous to the way we define delegation of public identifiers, it will be possible for a catalog search to have only a public identifier. (See the text about override).

Do we need to say that more explicitly. Where?

References for RELAX and TREX.

Resolved: 19 Mar 2001. References will be non-normative. Action to editor to provide.

Do we want to have a namespace entry type. What does it do?

Resolved: 19 Mar 2001. No, we have a general URI entry instead.

If the catalog resolver is handed a system identifier that begins "urn:publicid:", what should we do?

Resolved: 14 May 2001: unwrap the URI, turn it into a proper public identifier, and treat it as if that's what was seen. If this results in two different public identifiers, that's an error.

Do we want to create a TR9401 namespace to handle all of TR9401 in our XML catalog.

Resolved: 30 Apr 2001: non-normative appendix.

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?

Resolved: 07 May 2001: No. If an application retrieves a catalog that it does not understand, it should behave as if it was unable to find the resource. And recover as per issue 15.

Should we add a PI to point to a starting catalog set?

Resolved: 19 Mar 2001. Yes. Non-normatively and optionally.

Should we add an oasis:publicLocation attribute to handle what XML Schemas elected not to support?

Resolved: 14 May 2001: No. The urn:publicid: scheme gives us what we want.

Do we need a version attribute? What is our versioning strategy?

Resolved: 14 May 2001: no version number in the namespace name, no verison attribute; catalog processors are required to silently ignore elements that they do not recognize. (See minutes.)

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

Resolved: 07 May 2001: Yes.

Is the nextCatalog URI subject to resolution?

Resolved: 17 Apr 2001. No.

In part B of 9401, there is a system of default names of the catalog, which gives the implementation a way to bootstrap itself when finding the catalog. Do we want to do the same?

Resolved: 16 May 2001. Yes. Sort of. If the catalog process has an empty list of catalog entry files, it should use a file called xcatalog, located as a relative URI with respect to the document being processed, as its catalog. If the base URI is not known, do nothing.

Why do we distinguish between system identifiers and other URIs?

Resolved: 23 May 2001. Becuase they're different. The proposal to remove this distinction was rejected.