OASIS Darwin Information Typing Architecture (DITA) TC

I am implementing the catalog generation logic as part of the RNG-to-DTD and XSD process. By generating the catalogs it opens up some options for how to organize the catalog files. Through 1.2, the OASIS-provided catalog was just a single file for DTDs and a single file for XSDs that had entries for all the modules, both version-independent and version-specific. For 1.3 we have a couple of differences: 1. We're maintaining both the 1.2 and 1.3 vocabulary in the SVN repository, with the 1.2 vocabulary now being generated from the 1.2 RNG files (I created the 1.2 versions of the RNG files as the starting baseline from which the 1.3 were then developed, since it allowed me to test the RNGs against a known good set of exemplars, the 1.2 DTDs and XSDs). 2. Jarno and I are in agreement that the OASIS-provided shells and modules should be deployed as normal OT plugins rather than having their current privileged location within the OT. That will both make all vocabulary management consistent within the OT and make it easier to configure which version(s) of the vocabulary you want to have and now to configure the master catalog (because each OT plugin can contribute to the master catalog. To best support the 1.3 world I'd like to have a separate catalog for each version of DITA (1.2 and 1.3) and, for each DITA version, a catalog for each package Thus, I propose we organize the catalogs as follows for the OASIS-provided vocabulary distribution: doctypes/ catalog.xml -> includes the 1.3 catalogs before the 1.2, giving the 1.3 catalogs resolution precedence for version-independent public IDs and URNs. 1.2/ catalog.xml (same pattern as 1.3) 1.3/ catalog.xml -> Includes the top-level catalog for each schema type dtd/ catalog.xml -> Includes the catalog for each package base/ catalog.xml bookmap/ catalog.xml ... technicalContent/ catalog.xml xsd/ catalog.xml ... (same pattern as DTDs) rng/ catalog.xml ... (same pattern as DTDs) rnc catalog.xml ... (same pattern as DTDs) I could, of course, also provide the option to generate a single catalog with all the 1.2 or 1.3 entries in it. But I think this more-modular organization is the better approach for the OASIS-provided catalogs. Does anyone object to this scheme for organizing the OASIS-provided catalogs? Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com

I like it. It adheres to the principle of least surprise. Best Regards, Bob Thomas On Sat, Mar 22, 2014 at 12:24 PM, Eliot Kimber < ekimber@contrext.com > wrote: I am implementing the catalog generation logic as part of the RNG-to-DTD and XSD process. By generating the catalogs it opens up some options for how to organize the catalog files. Through 1.2, the OASIS-provided catalog was just a single file for DTDs and a single file for XSDs that had entries for all the modules, both version-independent and version-specific. For 1.3 we have a couple of differences: 1. We're maintaining both the 1.2 and 1.3 vocabulary in the SVN repository, with the 1.2 vocabulary now being generated from the 1.2 RNG files (I created the 1.2 versions of the RNG files as the starting baseline from which the 1.3 were then developed, since it allowed me to test the RNGs against a known good set of exemplars, the 1.2 DTDs and XSDs). 2. Jarno and I are in agreement that the OASIS-provided shells and modules should be deployed as normal OT plugins rather than having their current privileged location within the OT. That will both make all vocabulary management consistent within the OT and make it easier to configure which version(s) of the vocabulary you want to have and now to configure the master catalog (because each OT plugin can contribute to the master catalog. To best support the 1.3 world I'd like to have a separate catalog for each version of DITA (1.2 and 1.3) and, for each DITA version, a catalog for each package Thus, I propose we organize the catalogs as follows for the OASIS-provided vocabulary distribution: doctypes/  catalog.xml -> includes the 1.3 catalogs before the 1.2, giving the 1.3 catalogs resolution precedence for version-independent public IDs and URNs.  1.2/    catalog.xml    (same pattern as 1.3)  1.3/    catalog.xml -> Includes the top-level catalog for each schema type    dtd/      catalog.xml -> Includes the catalog for each package      base/        catalog.xml      bookmap/        catalog.xml      ...      technicalContent/        catalog.xml    xsd/      catalog.xml      ... (same pattern as DTDs)    rng/      catalog.xml      ... (same pattern as DTDs)    rnc      catalog.xml      ... (same pattern as DTDs) I could, of course, also provide the option to generate a single catalog with all the 1.2 or 1.3 entries in it. But I think this more-modular organization is the better approach for the OASIS-provided catalogs. Does anyone object to this scheme for organizing the OASIS-provided catalogs? Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Bob Thomas +1 720 201 8260 Skype: bob.thomas.colorado Instant messaging: Gmail chat ( bob.thomas@tagsmiths.com ) or Skype Time zone: Mountain (GMT-7)