minutes from ER teleconference 20010108

[Lauren Wood <lauren@softquad.com>]

Roll: Dave, Lauren, Paul, Norm, Tony

Agenda:

1) moving the time of the phone call. 10 - 11 am Pacific time; Norm will
move the teleconference time. No objections. Norm or Lauren will update
the web page.

2) FAQ entry aimed at new xml-dev readers: postponed to email. We need
the executive summary, and maybe should have a slightly longer version
as well.

3) System ID delegation: would be useful but it's hard since there's no
syntax for hierarchical URNs. DELEGATE only requires some prefix, and it
can include the "/" or ":" itself. Paul sees use in delegating system
IDs as long as they have a different keyword to public IDs. Norm is
willing to try to figure out the ramifications. There are a lot of
tricky issues; maybe we should put it on the back burner for the time
being. 

4) look at Norm's proposal:
empty elements easier to deal with in streaming environment
syntax for mapping public:
<public publicId="xxx" uri="yyy"/> - no objections
<system systemId="xxx" uri="yyy"/> - no objections

<delegate publicIdPrefix="xxx" catalog="yyy"/> (delegating public IDs;
the system IDs are on the back burner). Semantic is if the public
identifier uses the initial substring(called prefix), and there is no
perfect match in this catalog, then you fetch the other catalog (TR 9401
has the exact semantics). The word prefix is tricky, since what we mean
is the starting substring, and prefix is used by namespaces. 
Potential names: publicIdStart veto: Norm
publicIdStartString
publicIdStartsWith veto: Dave
publicIdInitialSubstring veto: Tony
So we will go with publicIdStartString, though this decision may be
revisited. 

Now we have two contentious issues left.

What do we call the top-level element? Norm proposes catalog. No
objections. It has the override attribute, which implements the override
functionality of TR 9401. We need to define what happens if this isn't
defined in the catalog. We could make override required. This is an
issue. We may want to go beyond 9401, which makes it
implementation-dependent. 

When you want to change the xml:base or override semantics of a subset
of the catalog, what should you do? Norm proposes a nesting catalog
element. No objections.

How do we say this catalog "includes" or "imports" another one; this
only takes place when you don't find a match in the first one. It looks
like xslt:import. Can you have an import anywhere that the catalog
appears? The semantics are that it takes effect at the end of the
catalog. This seems like a fallback, but it often isn't used that way.
The xslt:import semantics are difficult to understand. We could force
the element to go at the end of the file. We could add the semantics of
including where the element is; objections to that. Since SYSTEM matches
are used before PUBLIC, etc, then the order can be significant, but
isn't always. Norm has made a new issue for this. 

Try to just figure out what we call it to start with. TR 9401 defines
the catalog to be an ordered list of catalog entries, and the included
catalog inserts its entries at the end of the current list. Nested
catalog elements can have their own included catalog - what's the
semantic there? The xml:base and override do not carry into the included
catalog. You do an in-order traversal of the catalog tree. A nextCatalog
entry inserts a new node in that catalog tree. This means you don't have
to construct the whole tree. You could order the entries to get that
semantic anyway. We could restrict all nextCatalog entries to be at the
end; this would be the same behaviour as if they're sprinkled
throughout. The nesting we have here seems to be confusing. Using the
same element name for the outermost wrapper and the xml:base and
override value carrying could be adding to this confusion. 

Paul proposes changing the nested element name. 

The name of the thing that points to the next catalog: nextCatalog - no
objections. The attribute is called "uri" - no objections.

Interior nested element: Norm proposes "group" (perhaps until we come up
with something better) - no objections.

Should the "delegate" element's attribute currently called "catalog" be
called "uri"? Some discussion - leave as "catalog" for the time being -
open issue. 

Lauren