Eliot Kimber wrote: > Hussein Shafie wrote: >> The contents of all *atalog.xml files discovered by XMLmind XML Editor >> during its startup are programmatically merged into one giant, private, >> XML catalog used by our product. More info in >> http://www.xmlmind.com/xmleditor/_distrib/doc/configure/addon_discovery.html >> >> >> This XML catalog is really private: it is only used by XMLmind XML >> Editor (and by the Saxon bundled with our product during the execution >> of "process" commands). > > This is the problem and is, I think, a design bug (and a bad one).
May be. > The problem is that in catalogs, the order of occurrence of entries for > the same PUBLIC or SYSTEM ID determines which one is used: the first one > wins. > > In the case of DITA, the PUBLIC IDs/URNs of the .mod and .ent components > are the same for DITA 1.0 and DITA 1.1 (this is being discussed right > now in the DITA User List but in any case it's a done deal, at least for > now because DITA 1.1 is in the process of being approved by OASIS and > can't be changed or amended at this time). > In any case, it's fairly > common practice to have both version-inspecific and version-specific > versions of a given URI or PUBLIC ID, with the intent that the > version-inspecific one will resolve to the *latest* version. You mean the same public ID is used for specifying two different files. We didn't know that. We have never, ever, seen this way of using catalogs. Is this really kosher? > In a case > where you have two versions of an application active in the same > environment, as I do, "latest" may be context dependent. This context > can be established by using different catalogs to resolve the same > version-independent URI or PUBLIC ID. But only if you can control which > catalogs are active for a given document to be processed. > > Thus, if the DITA 1.0 catalog is included *before* the DITA 1.1 catalog, > you will get the sort of error I experienced: a parameter entity > declared in a 1.1 .mod file is not declared in the corresponding 1.0 > .mod file. Doh! Your diagnostic seems correct. > I think the correct solution would be to have per-configuration catalogs. Not sure. See below. > That is, having chosen a specific configuration for a given document, > you only consider the catalogs explicitly included by that > configuration, normally a single top-level catalog (which can then > include any other catalogs it wants). For example, OxygenXML provides > the ability to have per-project catalog configurations, for exactly this > reason. > > Since the order of processing of the different add-ons by XML Mind is > not predictable (even if you guys know the order, you're not going to > guarantee it to be stable and it's going to be arbitrary anyway, such as > the ASCII collation sequence of the directory names or something) it's > not possible to reliably control which catalogs are processed first. That's right. * XMLmind XML Editor loads a set of add-ons and unless you use dirty tricks (documented: http://www.xmlmind.com/xmleditor/_distrib/doc/configure/addon_types.html), the set should be considered as unordered. * XMLmind XML Editor loads a set of XML catalogs and currently, this set indeed is unordered (no workarounds). > Given this catalog processing behavior of XML Mind, I would consider it > fundamentally broken and unsuitable for general use since there is no > way, at this point in time, that I can use it for my stuff, simply > because I will be unable to reliably resolve entities via catalogs, > which otherwise I would be able to do. A bit severe, isn't it? However thank you for having attracted our attention to what seems to be a bug caused by our lack of knowledge of the XML catalog standard.
