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: DITA 1.2 catalog and doctype identifiers and related matters


Here is a summary of some information for DITA 1.2 that Robert, Eric, Paul, and I have been discussing privately.

 

I don’t think any of this is new. It is really just a confirmation of decisions that were made previously.  I don’t think it requires formal approval by the DITA TC at this time, but comments are always welcome. The TC will have a chance to formally review all of this as part of approving the DITA 1.2 specification including the DTDs, Schemas, and related files.

  

We agreed to use the following design patterns for doctype and catalog identifiers:

 

urn:oasis:names:tc:dita:xsd:<filename.xsd>:<version>
urn:oasis:names:tc:dita:xsd:spec:<spec-name><filename.xsd>:<version>
 
PUBLIC "-//OASIS//DTD DITA <version> <type>//EN"
PUBLIC "-//OASIS//DTD DITA <version> <spec-name> <type>//EN"

 

where <version> is optional and can be of the form:

      m.n : where “m” is the major release number and “n” is the minor release number.

      m.x : here the “x” is a literal “x” and selects the most recent major release.

  omitted : this is the generic identifier and selects the most recent release (any major or minor release).

 

That gives identifiers that look like this:

 

urn:oasis:names:tc:dita:xsd:topic.xsd

urn:oasis:names:tc:dita:xsd:topic.xsd:1.x

urn:oasis:names:tc:dita:xsd:topic.xsd:1.1

urn:oasis:names:tc:dita:spec:learning:xsd:learningAssessment.xsd

urn:oasis:names:tc:dita:spec:learning:xsd:learningAssessment.xsd:1.x

urn:oasis:names:tc:dita:spec:learning:xsd:learningAssessment.xsd:1.2

 

PUBLIC "-//OASIS//DTD DITA Topic//EN"

PUBLIC "-//OASIS//DTD DITA 1.x Topic//EN"

PUBLIC "-//OASIS//DTD DITA 1.1 Topic//EN"

PUBLIC "-//OASIS//DTD DITA Learning Assessment//EN"

PUBLIC "-//OASIS//DTD DITA 1.x Learning Assessment//EN"

PUBLIC "-//OASIS//DTD DITA 1.2 Learning Assessment//EN"

 

There will be generic, 1.x, and 1.2 versions for everything.  For new components there will only be generic, 1.x, and 1.2 and versions. So there will be generic, 1.x, and 1.2, but not 1.0 or 1.1, versions for the Learning and Machine Industry specializations.

  

In the DITA 1.1 materials there were only identifiers for DTD doctype shells and not for modules. There will be version numbers for everything in DITA 1.2.  This is required for the next item.

 

There was a call for using versioned identifiers within the shells and modules to make it easier to have more than one active version (1.1 and 1.2 say) installed at the same time.  Robert has implemented this in the preliminary DITA 1.2 DTDs. Even with this change it won’t be easy to have DITA 1.1 and DITA 1.2 in use at the same time since the DITA 1.1 shells and modules use generic (unversioned) references to modules and those references would resolve to DITA 1.2 rather than DITA 1.1. This will get better when we reach DITA 1.3 when you’ll be able to work with parallel versions of DITA 1.2 and DITA 1.3.

 

In the DITA 1.1 materials there weren’t generic schema identifiers, but only URNs with a version of 1.1. Generic URNs will be added in DITA 1.2.

 

The following generic identifiers for schema doctype shells will need to be maintained for compatibility with previous releases:

 

bookmap.xsd

concept.xsd

ditabase.xsd

glossary.xsd

map.xsd

reference.xsd

task.xsd

topic.xsd

 

In addition to the doctype shells that were included in DITA 1.1, a few additional shells will be added in DITA 1.2:

            A Machine Industry Task shell

            A Basic Topic shell that includes no domains (What should we name this? Is “Basic” OK or would “Simple” be better?)

            A Basic Map shell that includes only the mapgroup-d domain (Is this one necessary?)

 

The Hazard Statement domain will be added to all of the DITA topic and map doctype shells that include topic based domains and including Hazard Statemetn makes sense.

 

This last bit is much less settled, but I am suggesting that we include several different ditabase doctype shells for different packages where each ditabase shell includes all of the topic types and domains that are included in the package.  I’ll send out a more detailed and specific list.

 

   -Jeff



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