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: A different model for handling backwards compatibility (sorry long)

After some new thought, I think that the DITA community's approach to
backwards compatibility is expedient but long-term not efficient.

Let's say that "someday" we are going to make a backwards-incompatible
change like changing the element name syntax or the ID syntax. Here is
the expedient approach we use today:

 * We can't change this today

 * let's not think about it

 * let's wait for more and more content to be made in the old way

 * when we get around to wanting to change it, it will be much harder or

Result: backwards compatible changes will almost never happen. The
result of the result: DITA will accumulate more and more cruft over

My alternate proposal:

 * We can't change this today

 * think about and debate it -- do cost benefit analsys ("is xml:id
right for DITA? Is the benefit worth the high cost of implementing it?")

 * define the new way and document it as quickly as possible

 * implement the new way alongside the old way as quickly as possible
("Every DITA element can have either an 'id' or 'xml:id' attribute --
xml:id is preferred")

 * ask customers to use the new way instead of the old way ("The 'id'
attribute is deprecated")

 * remove the old way -- years or even decades down the road

This is a very proven mechanism for implementing backwards incompatible
changes. Using basically this technique, many companies have migrated
from K&R C to ANSI C to C++. The sooner we figure out what backwards
incompatible changes we need to make, the longer we can overlap the new
way and the old way and the more we can ease the transition for our
customers. Delaying it just increases the amount of content done in the
"old way" and makes the transition that much more painful.

This is ESPECIALLY true for DITA, which is just STARTING to take off
worldwide. DITA's growth will be greatest in the next year and in
retrospect (nobody's fault) I'm sorry we haven't been more aggressive
about figuring out what backwards compatible changes we need. (on the
other hand, a year ago only IBMers understood DITA, so the process would
have been difficult)

I propose that we go through this process after DITA 1.1. It's a
separate issue WHICH backwards compatible changes to schedule, but my
main point is: let's stop deferring them. Backwards incompatibility is
an argument for doing something sooner.

 Paul Prescod

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