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

Some specific thoughts about migration for practitioners who have created specialization or constraint modules ...

For the most part, I think this can be handled almost with a simple flow (although I'm sure that I am missing something obvious):

  • Have you specialized any of the following elements? [Followed by a list of elements with changes to content models, attributes, or specialization base]
    •  No -- You're good.
    • Yes -- You've got some work to do.
  • Do your constraint models reference any elements or attributes that have been removed?
    • No -- You're good.
    • Yes -- You've got some work to do.
  • Have you constrained any elements for which we have modified the content model model or attributes?
    • No -- You're good.
    • Yes -- You've got some work to do.

Robert, how would changes that we've made to entities or the filter attributes affect this?


Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
+1 919 622-1501; kriseberlein (skype)

On 10/15/2019 10:22 AM, Zoe Lawson wrote:
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]