Managing non-DITA XML in Tridion Docs

Greetings,

We have converted a very large set of our legacy content to DITA, but we have some products that we are not certain yet that we want to convert. Nonetheless, we need to get it out of our legacy CMS while still making it possible to maintain it and publish.

I've been playing with the Other folder type and imported these legacy XML files, and I can successfully "publish them" (although I don't have the transform yet integrated with SDL). I would like to enhance the functionality so that I can still check the files out to our XML editor and validate against our legacy schema, as well as preview the content in Tridion Docs. Neither of these objectives seem unattainable, but I wanted to see if anyone else has attempted to do this and what degree of success you've had.

Thanks,

Parents
  • Tridion Docs is capable of handling any DTD based system, and this is actively used by some legacy pre-DITA customer. Out-of-the-box we offer OASIS-DITA end-to-end, ranging from preconfigured plugins (linking), reports, validation, schemas/DTDs, previews, Content Editor, publishing, DITA-OT, etc

    The Other (template) type works for 'binary' storage. If you really want to use AuthoringBridge and publishing, I think you should actually submit that as Content Objects (maps, topics, libs) but in turn one-by-one you'll have to configure the above features to make it work which is quite an effort.

    In practice, depending on the legacy-size, you should either bite the bullet and move to DITA -or- indeed store them using the Other type and use the CMS Web Client to download/checkout the file and use your standalone configured xml editor and use the CMS Web Client upload/Checkin function.
Reply
  • Tridion Docs is capable of handling any DTD based system, and this is actively used by some legacy pre-DITA customer. Out-of-the-box we offer OASIS-DITA end-to-end, ranging from preconfigured plugins (linking), reports, validation, schemas/DTDs, previews, Content Editor, publishing, DITA-OT, etc

    The Other (template) type works for 'binary' storage. If you really want to use AuthoringBridge and publishing, I think you should actually submit that as Content Objects (maps, topics, libs) but in turn one-by-one you'll have to configure the above features to make it work which is quite an effort.

    In practice, depending on the legacy-size, you should either bite the bullet and move to DITA -or- indeed store them using the Other type and use the CMS Web Client to download/checkout the file and use your standalone configured xml editor and use the CMS Web Client upload/Checkin function.
Children