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?
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+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.
Zoë