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: RE: [dita] Catalogs: embedding version numbers

Versioning and naming is a complex issue that
could burn lots of cycles.  I hope we can avoid
that at least at this time.
Putting the version into the public identifier
is a good idea.
Not fooling with the namespace (as Eliot suggests)
is also a good idea.
Putting the version number into the (unpathed) file
name is a bad idea.  It will make maintenance of the
various files quite difficult.  Instead, the entire
inter-related "tree" of dtd/schema files should all
maintain the same names, and then the root of the
tree should change for a different version.  This
is how docbook does it; it's how the IBM toolkit
does it (for the most part); it's how most software
management systems (e.g., Clearcase) do it.

From: Chris Wong [mailto:cwong@idiominc.com]
Sent: Thursday, 2005 September 01 15:01
To: DITA-TC (E-mail)
Subject: [dita] Catalogs: embedding version numbers

DITA includes OASIS catalogs as part of the standard. I propose for DITA 1.1 we somehow embed the version number in the catalogs so possibly incompatible DTDs from pre-1.0, 1.0 and 1.1 can coexist. Right now, pre-1.0 and 1.0 can coexist in the same catalog because their public IDs differ, most notably in the change of owner from IBM to OASIS. I'd like to continue this pattern by adding version numbers to the DITA 1.1 DTD files' public IDs. For example, concept.dtd from all three versions can sit in the same catalog like:
<public publicId="-//IBM//DTD DITA Concept//EN" uri="toolkit-1.3.2/concept.dtd"/>
<public publicId="-//OASIS//DTD DITA Concept//EN" uri="1.0/concept.dtd"/>
<public publicId="-//OASIS//DTD DITA Concept 1.1//EN" uri="1.1/concept.dtd"/>
We might want to embed the version number in the filename too, like concept11.dtd. This should bring us in line with other models like SVG.

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