Move Our DITA Content to Another CCMS? Seriously?  gg Heath and Nancy Howe, Teradata

 September, 2016

2

No, Really….

© 2016 Teradata

3

•  At Teradata, we provide end-to-end solutions and services in data warehousing and big data and analytics that enable you to become a data-driven business…one that’s positioned to increase revenue, improve efficiency, and create the most compelling experience for your customers.

•  Find out more at http://www.teradata.com

Who is Teradata?

© 2016 Teradata

4

 Today we’ll be sharing how Teradata is taking DITA content out of one proprietary CCMS and putting it into IXIASOFT DITA CMS.

•  Manage over 60 programs a year

•  Approximately 300 deliverables

•  Staff of ~40

•  70 percent content reuse

•  ~50,000 files (maps, topics, images)

•  ~120 ditaval files

•  DITA, FrameMaker, and Word sources

What’s Our Story?

© 2016 Teradata

5

Where Did We Start?

© 2016 Teradata

•  Information Engineering tools and technology under constant evaluation

•  Requirements to: –  Reduce number of tools

–  Save associated costs (software and people)

–  Find an easily maintained and extensible CCMS

–  Make it easier to connect to third-party tools

•  Picked a CMS

•  Tested features with our content

6

Astoria IXIASOFT DITA CMS

Approval labels DRM versions

Effectivity/XPath DITAVAL

Conref containers Referable-content topics

Readable file names Auto-generated file names (CSH)

Major Feature Differences

© 2016 Teradata

7

•  Astoria approval labels: –  Freeze content for a deliverable map

–  High maintenance to apply labels when changes occur

•  IXIASOFT DRM: –  Manage updates to multiple documents across various releases

Approval Labels vs. Dynamic Release Management

© 2016 Teradata

8

•  In Astoria we used xPath for conditional, elemental filtering:

We had to learn how to include/exclude elements

•  For IXIASOFT DITA CMS we needed DITAVAL files which required: –  Creating DITAVALs for every deliverable

–  Testing output

–  Dovetailed with filtering requirements for translation output

Filtering (Effectivity vs. DITAVAL)

© 2016 Teradata

9

•  Initial implementation in Astoria was single topics containing multiple conref-able elements –  Not the best DITA practice

–  Grew unwieldy fast

–  Not easily maintained

•  For IXIASOFT, elements had to be broken out into individual conref-able elements –  Some were entire topic bodies

–  Some were topic elements inside a topic body

Referable Content

© 2016 Teradata

10

•  Astoria uses human-readable file names

•  We could control the filenames

•  Direct linking in context-sensitive help to Ixiasoft file names broke the links –  Helped engineering find a way to use the .csh file from Eclipse help

–  Had to add <resourceid> strings to linked topics

File Names and Help Deliverables

© 2016 Teradata

11

•  Migrate only current content, no legacy

•  Content clean up

•  Migration responsibilities

•  Break up our conref containers into referable-content topics

•  Development then Production

•  Import into a single DRM version (Import)

•  Determine what content would be migrated and when

•  Migration!!!!

Our Migration Process

© 2016 Teradata

12

The Journey Begins

© 2016 Teradata

13

•  How do we burst our conref containers? –  Inside Astoria?

–  Inside Ixiasoft?

–  After export and before import?

•  How do we maintain the conref referential integrity?

•  Decided on a script to be run in between CCMSs

•  Tweaking on the script was majorly iterative and fairly extensive

Migration Process: Burst Conref Container Elements into Referable-Content Topics

© 2016 Teradata

14

•  Locates filenames that start with cc_

•  Retrieves topic ID

•  Finds all elements with ids

•  Outputs new files as referable-content topics

•  Associates new referable-content topics to their original references

Migration Process: How the Script Works

© 2016 Teradata

15

•  Rename all the conref container topics to “cc_<something>”

•  Consolidate duplicated content

•  Ensure we had no duplicate filenames system-wide

Migration Process: Prior to Bursting

© 2016 Teradata

16

•  Bursting tests began at the beginning of February, 2016

•  Several months of tweaking the script

•  How big can our import packages be?

Migration Process: Testing and Tweaking

© 2016 Teradata

17

•  Normalize content

•  Related links (topic element inside a topic topic)

© 2016 Teradata

Migration Process: More Tweaking?

18 © 2016 Teradata

And that’s when Eric said…

19

•  Started with post-burst validation

•  Added pre-burst validation

•  Each validation gave us new issues to fix

Migration Process: Validate and Check for Completeness in oXygen

© 2016 Teradata

20

Migration Process: Validate and Check for Completeness in oXygen

© 2016 Teradata

Error Description

Duplicate element with ID <nameofid> found in the same topic context.

Conref container has more than one element with the same element ID.

Referenced topic ID <nameofid> does not exist.

Occurs when #id in the referencing href does not match the referenced topic id. This is caused by a change to the original id on the referenced topic and the href in the referencing topic is not updated to point to the new id.

Reference with external scope to non-DITA resource does not have the correct format attribute set. 

Xref must have following attributes: @format="html" @scope="external" @id="<id-of-xref>"

21

•  Support our move from Astoria to DITA CMS –  Needed to add title elements to maps

–  Missing type attributes on <note> elements had to be fixed

•  Perform cleanup –  Removed <category> element

–  Removed <othermeta> for showing/hiding comments

–  Added <resourceid> to context-sensitive help prologs

–  Removed scaling from graphics

Migration Process: oXygen Refactoring Operations

© 2016 Teradata

22

Migration Process: Flowchart

© 2016 Teradata

Export content from Astoria

Pre-burst validation and

fix errors

Conref burst

Post-burst validation and

fix errors

Refactoring operations

Post-refactoring validation

Import into Dev “Import “

DRM

Output validation

Import into Prod “Import”

DRM

Create new instances of maps in product DRMs

23

•  Wiki instructions for all to use

•  Continuous updates

Migration Process: Documenting Our Process

© 2016 Teradata

24

•  Bursting took many hours on our local workstations

•  Using a remote desktop for bursting reduced the time by 40-50%

•  Pre- and post-validation locally worked best

•  Refactoring operations done locally went faster than remotely

Migration Process: Making Life Easier

© 2016 Teradata

25

Import into one DRM

•  Allowed us to maintain our extensive re-use

© 2016 Teradata

Migration Process: Managing Re-use

26

•  When were deliverables due?

•  How could we leverage content synergies?

•  Training people at the right time

Migration Process: When to Migrate?

© 2016 Teradata

27

Migration Process: Migration!!!!!

© 2016 Teradata

28

•  Communication

•  Coordination

•  Testing, fixing, testing some more, validation, fixing, testing…

•  Taking that final leap

Migration Process: Key Factors to Successful Migration

© 2016 Teradata

29

Questions?

© 2016 Teradata

30

Nancy Howe

Nancy.Howe@teradata.com

1.858.485.2142

gg Heath

Gail.Heath@teradata.com

1.858.485.3639

Contact Information

© 2016 Teradata