TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
A priority of mine is to define the terms of what we do in ways that open our thinking about it. I'll insist that there is no necessary restriction of DITA to "traditional document structure". Outside of our thinking about it, and the language we use to express our thinking, that is. Sure there can always be something better. But digging in and doing it now helps flesh out the issues to inform that evolution.
One detail though... You don't necessarily need to add excessive metadata to your "record set". One idea behind DITA is that you render the same things differently, depending on the render context. In many cases, knowing the larger context, plus semantics (defList, ol, ul, glossary, etc.), is enough. This is especially true if you render at the last minute (dynamic rendering at request time).
Yes, sometimes you need to add special-case metadata at a finer level. But not always. And anyway, in my experience determining the data values to add in is the big issue... Squirting it into whatever markup is relatively trivial.
From: "mbaker -at- analecta -dot- com" <mbaker -at- analecta -dot- com>
To: 'Chris Despopoulos' <despopoulos_chriss -at- yahoo -dot- com>; techwr-l -at- lists -dot- techwr-l -dot- com
Sent: Tuesday, May 2, 2017 7:18 AM
Subject: RE: Structured stuff for the beginner
Chris,
If you take a traditional document structure and add a bunch of subject domain metadata to it so that you know what is in each row and column, then is it no longer a traditional document structure. You have turned it into a record set. Perhaps it is a little more verbose in its markup than if you had set out from scratch to create a record set, but it is still a record set, and as such can be transformed into all kinds of things.
The key is to apply the appropriate metadata to the content so that you preserve the possibilities inherent in it. The syntax matters, in that a more verbose syntax is more overhead, but the fundamental properties are the same.
Can you do this in DITA? Yes. You moved your content to the subject domain in DITA, and that gives you the advantages of the subject domain. Congratulations. That's a good thing and I am glad to hear about it.
Is DITA the most elegant tool imaginable for doing this? No.
Do I think people using DITA should use features like these to move their content to the subject domain when it is beneficial to do so? Yes.
Am I happy to see DITA moving in the direction of providing greater support for working in the subject domain? Yes, absolutely. Getting people moving to the subject domain is my priority.
Do I acknowledge the value of using a widely-supported technology, even if it is not ideal in all its particulars? Yes.
Do I think DITA represents an end state of documentation technology beyond which no worthwhile development is possible or should be contemplated? No.
Mark
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
