OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Catalog issue discussed at today's TC call


The first issue comes from a DITA-OT issue / dita-users post, but you'll have to scroll down for details (the update from Rodolfo Raya):
https://github.com/dita-ot/dita-ot/issues/2401

Specifically, DITA 1.3 defines the following catalog entries (in different catalogs):
<public publicId="-//OASIS//ELEMENTS DITA 1.3 Taskbody Constraint//EN"
uri="dtd/machineryTaskbodyConstraint.mod"/>
<public publicId="-//OASIS//ELEMENTS DITA Taskbody Constraint//EN"
uri="dtd/machineryTaskbodyConstraint.mod"/>
<public publicId="-//OASIS//ELEMENTS DITA 1.3 Subject Classification Domain//EN"
uri="dtd/classifyDomain.mod"/>
<public publicId="-//OASIS//ELEMENTS DITA Subject Classification Domain//EN"
uri="dtd/classifyDomain.mod"/>


Here are the equivalent versions in DITA 1.2. The machinery constraint included "Machinery" in the public ID; the classification domain included "Map":
<public publicId="-//OASIS//ELEMENTS DITA Machinery Taskbody Constraint//EN"
uri="machineryTaskbodyConstraint.mod"/>
<public publicId="-//OASIS//ELEMENTS DITA 1.2 Machinery Taskbody Constraint//EN"
uri="machineryTaskbodyConstraint.mod"/>
<public publicId="-//OASIS//ELEMENTS DITA Map Subject Classification Domain//EN"
uri="classifyDomain.mod"/>
<public publicId="-//OASIS//ELEMENTS DITA 1.2 Map Subject Classification Domain//EN"
uri="classifyDomain.mod"/>

I don't think we can remove any of the 1.3 shipped versions - doctypes could already be using them (the OASIS 1.3 doctype shells use them, and people have already developed based on those).

For the errata, we should add the DITA 1.2 level version-agnostic public IDs into our catalogs, so that 1.2 level shells can be updated as intended. We should probably also add 1.3 specific versions that use the 1.2 pattern. Strictly speaking this isn't necessary but without it I can imagine some people will be confused when changing 1.2 to 1.3 results in failure for these two modules.

The global issue across our catalogs is that in 1.2 we provided three Public IDs for every module:
1. A version-agnostic copy, meaning "The latest version"
2. A 1.x copy, meaning "The latest in DITA 1.x", allowing for easy upgrades across 1.x without automatic upgrade to 2.x
3. A version-specific copy, "This module as shipped in DITA 1.2"

For example:
<public publicId="-//OASIS//DTD DITA Base Topic//EN" uri="basetopic.dtd"/>
<public publicId="-//OASIS//DTD DITA 1.x Base Topic//EN" uri="basetopic.dtd"/>
<public publicId="-//OASIS//DTD DITA 1.2 Base Topic//EN" uri="basetopic.dtd"/>
<system systemId="urn:oasis:names:tc:dita:xsd:basetopic.xsd" uri="basetopic.xsd" />
<system systemId="urn:oasis:names:tc:dita:xsd:basetopic.xsd:1.x" uri="basetopic.xsd" />
<system systemId="urn:oasis:names:tc:dita:xsd:basetopic.xsd:1.2" uri="basetopic.xsd" />

In DITA 1.3, all of the 1.x copies are missing across all versions of the grammar. We should restore these in the errata.

Regards,

Robert D. Anderson
DITA-OT lead and Co-editor DITA 1.3 specification,
Digital Services Group


E-mail: robander@us.ibm.com
Digital Services Group
11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]