[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: New draft published: 27 Apr 2001
At 14:47 2001 04 27 -0400, Norman Walsh wrote: >I've put a new draft of the spec online at >http://www.oasis-open.org/committees/entity/spec-2001-04-27.html The catalog can be used in two different, independent ways: (1) it can be used to lookup the replacement text for an external entity, . . . s/lookup/locate/ or something. The catalog does not provide the replacement text, it provides the location of the replacement text. The nextCatalog entry can be used to insert new catalog entry files... s/new catalog entry files/a new catalog entry file/ (a single nextCatalog entry can only insert one). The input to a resolver, such as the SAX entityResolver(), that locates external identifiers is a system identifier and optionally a public identifier. Suggest you change the commas to emdashes (otherwise, it's tempting to parse "that locates" as modifying "SAX entityResolver()" on first pass). The delegateURI entry indicates that URIs that starts with the specified... s/starts/start/ The initial search strategy in force at the beginning of each catalog entry file depends on the preference as determined by the application (possibly under user control). An application must provide some way (e.g., a runtime argument, environment variable, preference switch) that allows the user to specify which of these modes to use in the absence of any occurrence of the override attribute on the catalog entry. The parenthetical phrase in the first part above implies that the initial search strategy MAY be under user control, but then the next sentence implies it MUST be under user control. (I realize this language came from TR9401.!) General: Why do we have all uppercase URI in delegateURI but we have all lowercase uri for the uri entry type? In addition, unqualified attributes, other than the attributes explicitly described in this Specification, are reserved for future use. Do we mean just unqualified attrs on elements within our namespace, or all unqualified attrs even when in the starttag of an element in another namespace? (I think we should mean the former, in which case we need to reword that above quoted statement.) Also, if a namespaced element in another namespace is ignored, then its content could contain an element in our namespace and it would be ignored too, right? Need we make this clear? Search through the document for "opne"; there are two occurrences, and both should be changed to "open". I see you've decided to do systemid delegation before publicid matching. Since delegation is sort of saying "I don't have a match in this catalog entry file, so try elsewhere", I could see an argument for doing publicid matching before systemid delegation. Could you outline the pros and cons of each, preferably giving some user scenarios that would support one or the other order? In the External Identifier Resolution algorithm, I question whether step 8&9 are correct. I don't see the catalog lookup process as returning the originally given system id, I see it as returning one of the right hand sides from the catalog or "no match". It is up to the calling application to decide what to do with "no match". In the case that there was an original system id, it would presumably use it, but that's not for us to say. And in the case that there was no original system id, it's not necessarily an error--it's just that this catalog lookup failed to find a match. Quoting from our own introducation: This specification does not dictate when an entity manager should access this catalog; for example, an application may attempt other mapping algorithms before or (if the catalog fails to produce a successful mapping) after accessing this catalog. I'd like to see step 8 and 9 replaced by a single step that says something like "Indicate to the calling application that no match was found." Under URI Resolution, step 1, s/catalog file/catalog entry file/. Under URI Resolution, the 6 step algorithm, as I discuss above, replace step 6 with "Indicate to the calling application that no match was found." XML Catalogs support this feature with a processing instruction, “<?oasis-xml-catalog>”, which allows a document ... No they don't. That PI is not in the catalog, and is not supported by XML Catalogs. It has to be supported by XML parsers that support XML Catalogs. The best we can do is say that "This resolution suggests that XML parsers incorporating XML Catalog support recognize such PIs to allow a document...." (I'm still not convinced we want to do this.) The <?oasis-xml-catalog> processing instruction must appear in the prologue. That means it could appear in the middle of the internal subset. I thought we said it had to appear before the doctype decl, if any. (And if we do that, that obviates the need for the second bullet.) The URI that identifies the catalog file might not be subject... s/catalog file/catalog entry file/ paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC