[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