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] Prototype DITA 1.1 DTDs

I'm not against DITA 1.1 doctypes but I'd like to understand the real problem. If you replace your DITA 1.0 DTDs with DITA 1.1 DTDs, everything should continue to work. That's what backwards compatibility of the DITA 1.x series is about. The only problem would be if a 1.1 document ended up on a desktop with only 1.0 installed. But this would be a problem in any case.
Version-dependent doctypes can cause problems. The user will install a new version of their tools and DTDs and find that they have no access to DITA 1.1 elements until they update their DOCTYPE statements. If we presume a low-tech user, this could involve manually changing hundreds of documents to get access to those new elements. I don't really see such a user as "lazy". Lazy binding is a very common and valid technique. Programmer classes seldom have version numbers in their interfaces because of exactly this issue.
The obvious compromise is to create both version-dependent and version-independnt public identifiers, but I would like to understand precisely what problems were caused by the current scheme in case it is something that should be fixed in the DITA DTDs (in particular, if a backwards incompatibility introduced).

From: Rodolfo M. Raya [mailto:rmraya@heartsome.net]
Sent: Tuesday, June 13, 2006 3:45 PM
To: Robert D Anderson
Cc: dita@lists.oasis-open.org
Subject: Re: [dita] Prototype DITA 1.1 DTDs

On Tue, 2006-06-13 at 16:34 -0500, Robert D Anderson wrote:
We've talked in the past about having version specific public IDs available
in the catalog, but we would also have the version-agnostic version. The ID
with no version would always point to the latest set of document types.
This allows users to update their DTDs without having to update the DOCTYPE
in their files.

Of course, that particular concern is only a worry for the actual DTD
files, not for the modules. So, I'm not sure if we want the modules to use
public IDs with versions. My guess would be no, for consistency... but are
there any other opinions?


IMHO, each DTD and module version should have its own version number in the PUBLIC ID. This is the standard procedure that you can find in other XML vocabularies, like DocBook.

DTDs and catalogues are different things. Lazy users can play with their catalogues and make them point to the latest version without updating DOCTYPE declarations in their documents, but people dealing with different versions should be able to differentiate them in a catalogue.

FWIW, I found the problem while preparing my main catalogue to handle DITA 1.0 and DITA 1.1 at the same time. I expect user of my tools to have DITA 1.0 files, DITA 1.1 files and also their own customisations of DITA. My programs should be able to resolve the right entities and  now the entity resolver cannot differentiate between DITA 1.0 and DITA 1.1 because the DTDs have the same PUBLIC IDs .

Please keep in mind that not only technical writers deal with DITA files. I work with translation tools and for my company it is important to handle any official  version of DITA, without asking translators (our end users) that know nothing about DTDs and catalogues to tweak configuration files every time they get a DITA document to translate.

I think that this issue needs to be carefully reviewed.

Best regards,
Rodolfo M. Raya
The information in this e-mail is intended strictly for the addressee, without prejudices, as a confidential document. Should it reach you, not being the addressee, it is not to be made accessible to any other unauthorised person or copied, distributed or disclosed to any other third party as this would constitute an unlawful act under certain circumstances, unless prior approval is given for its transmission. The content of this e-mail is solely that of the sender and not necessarily that of Heartsome.

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