
XML Catalog Issues
Document
Working Draft 23 May 2001
This document tracks open issues in the OASIS Entity
Resolution Technical Committee.
- 1.
-
Which schema language is normative?
Resolved: 22 Jan 2001. Prose is normative, schemas
provided are informative.
- 2.
- 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.)
- 3.
- 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?
- 4.
-
Do we want to allow the catalog to map entity names to
URIs?
Resolved: 19 Mar 2001. No.
- 5.
-
What is the extensibility mechanism? Elements from
another namespace?
Resolved: 19 Mar 2001. Elements and attributes from
other namespaces.
- 6.
-
Can an extension element change the semantics of an
element from the catalog (non-extension) namespace.
Resolved: No.
- 7.
-
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.
- 8.
- Do we want to allow delegation based on system
identifiers (in addition to public identifiers). See the semantics thread.
- 9.
-
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.
- 10.
-
Should the nextCatalog directive be required to
occur only at the end of the catalog.
Resolved: 19 Mar 2001. No.
- 11.
-
What is the namespace name of our catalog?
Resolved: 30 Apr 2001. Norm will contact OASIS to get
an OASIS URN.
- 12.
-
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.
- 13.
-
Public identifiers for schema locations.
Resolved: 19 Mar 2001. Dropped. See issue 25.
- 14.
-
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.
- 15.
-
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.
- 16.
-
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.
- 17.
-
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.
- 18.
-
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?
- 19.
-
References for RELAX and TREX.
Resolved: 19 Mar 2001. References will be
non-normative. Action to editor to provide.
- 20.
-
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.
- 21.
-
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.
- 22.
-
Do we want to create a TR9401 namespace to handle all of
TR9401 in our XML catalog.
Resolved: 30 Apr 2001: non-normative appendix.
- 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?
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.
- 24.
-
Should we add a PI to point to a starting catalog set?
Resolved: 19 Mar 2001. Yes. Non-normatively and
optionally.
- 25.
-
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.
- 26.
-
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.)
- 27.
-
Is the 'override' attribute poorly named. Would another
name like 'prefer' with the values 'system' and 'public'
be clearer?
Resolved: 07 May 2001: Yes.
- 28.
-
Is the nextCatalog URI subject to resolution?
Resolved: 17 Apr 2001. No.
- 29.
-
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.
- 30.
-
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.