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: Starting thoughts on a migration document

I have thoughts on a very (very) rough outline of a migration document for DITA 2.0.

  • Overview of changes (would this be more or less detailed than the spec?)
  • Migrating DITA Source
  • Migrating DITA Tools

Each Migrating section would have a similar structure:
  • Overview of suggested method
  • Suggested tools
  • Prepare for migration (analysis, get nifty scripts from GitHub, etc.)
  • Easy things - stuff that can be done with search and replace or some quick tool
  • Moderately complicated things - minor refactoring, such as taking all @alt and moving to <alt>
  • Hard things - stuff that requires rewriting/reworking
  • Optional things - e.g. here are new elements/attributes you might want to use
  • Clean up
The order of operations subject to change based on whatever it is we actually need to do. E.g. if you need to fix X before you can do Y, even if it's hard, it needs to come earlier in the order.

Each set of tasks would have all the base tasks first, then the technical content, etc.
The theory is that you can step through the document once and have migrated content at the end. 

I have never really extended DITA, so I'm ignorant. Does there need to be a different section for migrating specializations/extensions? Or is that just part of Migrating DITA Source?

I'm sure there will be much discussion about what is "easy" vs "hard", since that can be super subjective, but at least it's a start.


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