[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: minutes from ER teleconference 20010108
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC