Re: Time to Work on 1.x to 2.0 Migration Guidance and Tools

Unfortunately it looks like I can’t attend today (24 May) but I will see what I can do to move forward on these tasks.

Anyone who would like to assist can mail me directly at my ServiceNow email to coordinate.

Cheers,

_____________________________________________

Eliot Kimber

Sr Staff Content Engineer

O: 512 554 9368

M: 512 554 9368

servicenow.com

LinkedIn | Twitter | YouTube | Facebook

From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of kris eberleinconsulting.com <kris@eberleinconsulting.com>
Date: Tuesday, May 24, 2022 at 8:37 AM
To: dita <dita@lists.oasis-open.org>
Subject: [dita] RE: Time to Work on 1.x to 2.0 Migration Guidance and Tools

[External Email]

Hi, Eliot.

I’ve added this as an item on today’s agenda: “DITA 1.x to 2.0 migration work to be done”.

From what the TC has decided previously, such work includes the following:

Developing topic for the spec (and yes, there’s only a stub topic in place)
Authoring a committee note with information and guidance
Updating content in the OASIS Open repo for specializations removed from the standard:

Learning & Training specialization
Machinery task (document-type shell, constraint, domain)
Classification domain

Developing tooling to make migration simpler

Best,

Kris

From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> On Behalf Of Eliot Kimber
Sent: Sunday, May 22, 2022 2:46 PM
To: dita <dita@lists.oasis-open.org>
Subject: [dita] Time to Work on 1.x to 2.0 Migration Guidance and Tools

I’ve been working on freeing up time that I can apply to TC work (as well as attempting to update DITA for Practitioners to reflect DITA 1.3 and 2.0).

I initially volunteered to contribute to the migration documentation and tools and I’m in a position to start doing that work.

I would like to discuss how we can and should proceed with this work at the next TC meeting.

I think the work to be done is:

Write the Migrating from DITA 1.3 to 2.0 topic that’s currently a placeholder in the spec (if I’m looking at the latest source)
Implement a set of XSLT transforms to do as much migration as can realistically be automated.
(Optional) Implement as set of XQuery update operations that do as much migration as can realistically be automated (i.e., for use as Oxygen refactors or in the context of an XQuery database like BaseX or some such.