Hussein Shafie wrote: >> I have created a directory for the specialization in the addon >> directory. In there is a catalog file that contains this entry: >> >> <nextCatalog >> catalog="file:///c:/DITA-OT1.3.1/catalog-dita_template.xml"/> > > We are somewhat naive users of XML catalogs. For us, an XML catalog is > essentially a way to say: do not download the DTD from the Web, use this > local copy. > > I've never used <nextCatalog> in my life. So it will be hard for me to > quickly answer your questions. See below.
Have you read the catalog spec? http://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html In any case, nextCatalog allows you to chain catalogs together. The value of the catalog= attribute is the URI of the catalog, either absolute or relative to the location of the current catalog (or value of nearest xml:base= attribute). But I think the problem is actually with the order of processing of map entries. In order to create a more easily sharable test case, I started setting up my DITA tutorial configurations and specializations with XML Mind (http://www.xiruss.org/tutorials/dita-specialization/). The first thing I did was simply try opening one of my tutorial's topics. I expected it to fail (since it uses an absolute, non-resolvable URL to the DTD) but it succeeded, which I determined was because my other configuration, which points to my modified DITA OT catalog was still active. When I removed that configuration (thus removing the reference to that catalog), it failed as expected. That means there must be a difference in how the two local configurations refer to the DITA parts, which I will confirm. It also means that XML Mind is correctly resolving the nextCatalog references but there are still catalog-related issues with XML M ind (outlined below). >> I didn't see anything in the documentation on XML catalogs on how to >> control things like preference of SYSTEM or PUBLIC IDs. > > XMLmind XML Editor always prefers public IDs over system IDs. There is > no way to control that. That's not good in the abstract but probably OK in practice since normally one wouldn't have catalogs at all if one didn't prefer public IDs. >> It's also not clear what the interaction of different catalogs is, since >> all the add-ons appear to contribute catalogs (or do they?). > > That's right. This has proven to be very convenient. > > 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). 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. 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! I think the correct solution would be to have per-configuration catalogs. 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. 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. Cheers, Eliot -- W. Eliot Kimber Professional Services Innodata Isogen 8500 N. Mopac, Suite 402 Austin, TX 78759 (214) 954-5198 ekimber at innodata-isogen.com www.innodata-isogen.com
