OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: minutes from ER teleconference 20001127


Roll: Paul Grosso, Tony Coates, Lauren Wood, John Cowan, Norm Walsh,
David Leland, Karl Best (observer).

These people, other than Karl, having sent intent to become members of
the TC and having taken part in this first meeting, are the members of
the ER TC.

Nominations for secretary: Paul nominates Lauren. No other nominations.
No objections; thus Lauren is elected.

Nominations for editor: Lauren nominates Norm. No other nominations. No
objections; thus Norm is elected.

Technical discussion: "The catalog must provide the ability to map URIs
to alternate URIs (for example, namespace names)."
Paul doesn't want a generalized declaration, but maybe we should also
have an open-ended or default declaration. We could drop this as a
general requirement. Paul suggests changing requirement to be something
about namespace names and stylesheets, and change the "must" to a
"should". 

Concretely: replace with "The catalog should provide the ability to map
stylesheet URIs to alternate URIs" - no objections
and "The catalog should provide the ability to map namespace names to
alternate URIs" - no objections.

Throughout the requirements document, it refers to URIs, which are
restrictive. But maybe the system should be able to cope with this
anyway, so URIs should work. The question is whether the RHS should be
database calls etc, so a proposal is to use SOI on the RHS. A filename
that begins http on some system would be difficult to deal with. Then
there's the base issue, however that's defined in the catalog. In order
to support this catalog format, some implementation work will have to be
done, which could include supporting URI syntax. How do database calls
work? A scheme can be created, such as JDBC. Paul withdraws his
proposal.

"This document lays out ...": no amendments
"The catalog must be expressed in XML ([XML]) with a specified namespace
([XML Names])." This means that the document must have a xmlns
declaration and we will construct a namespace. OASIS will provide us
with a string that we can use as the namespace. Proposed: add The
namespace name will be provided by OASIS. No objections.
Proposed: "The catalog will be defined by an XML DTD and an XML Schema."
No objections.

Should we keep an issues list? Yes. The editor will keep this list. 

"The catalog must provide the ability to map public identifiers to
URIs." - no amendments or objections.

"The catalog must provide the ability to map system identifiers to
URIs." - no amendments or objections.

"When both a public identifier and a system identifier are present..." -
this expresses the OVERRIDE keyword in TR 9401. No amendments or
objections.

"The catalog must support xml:base..." - concern is that we will need to
consider what happens if XBase doesn't become a Rec in time. If we
support this, we don't need the BASE keyword. No amendments or
objections.

"The catalog must provide the ability to delegate..." - objection to the
"and URNs". Maybe we should have "delegate public" and "delegate
system". Proposal to strike the two words - no objections (but this
issue will be added to the issues document).

"The catalog must provide the ability to map notation names to URIs." -
Proposal to delete this requirement, since notation names are not
practically exposed by XML systems. No objections, thus this requirement
is deleted.

"The catalog must provide the ability to map entity names to URIs." -
Proposal to delete this requirement, since entity names can not occur in
XML without a system or public identifier. No objections; the issue will
be added to the issues list since we may want to add the capability
later.

"Where the functionality of the XML catalogs..." - must the limitations
also be identical? Yes. Where we want different behaviour, we will use a
different keyword. No objections.

"The catalog must provide an extension mechanism..." - elements from the
catalog have a defined namespace. Maybe elements from other namespaces
should be allowed for extensions - we can't really provide much beyond
that. Issues added to the issues list. No objections to this
requirement.

No other requirements were added.

Norm moves to adjourn at 3:05 Pacific time. He will send out revised
requirements and issues list this evening.

Lauren


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC