In those situations, why should we impose the extra time and effort to plug additional classification into the XML? For those tech writers, the end goal isn’t to make that XML as rich and complete as possible. The goal is to make the final publication as complete and effective as is appropriate for their end users.
Now we can look at classification and all the related ways of managing XML content in a whole new way.
The truth is, XML attribute classification is not enough.
Unless you deal with products simpler than a toaster, key words and metadata taxonomies struggle to hold all the complexity of the ways we manage product and document configuration.
It means we could continue adding and updating classifications to content until, in some cases, there’s more metadata than content.
In an optimal scenario, classification comes as a side effect or result of doing work, or of the data you’re working with, not as extra steps to input classification content into the XML topic.
For customers with products managed in a PLM environment, much of this semantic and product classification is already available.
Options and variants that are applied to product configuration, change information and release states of products – all are available to the tech writer to use, and not just as source information.
When the information can be inherited from the engineering and product world into technical documentation through technical publications software, and organized by both category or part relationships and reuse of parts directly as content, we realize multiple benefits:
- saving time – both in the initial creation of the illustration or topic, and in future research and updates to that content
- lower risk of inaccurate information – we’re applying it from the source, instead of re-creating, retyping, or reinterpreting it into a classification hierarchy
- all writers in the organization will have a more complete view of the entire ontology of information both available and applicable to documents and products
- we can modify and apply classification as needed, without driving additional, often inaccurate, revisions to the content
When we have to modify an XML topic simply to change the metadata, we’re imposing additional constraints and rules about how and where that topic can be reused.
At a minimum, writers would have to spend additional time analyzing if the change to the content impacts the other documents it is referenced from.
By relating the classifications that are not critical to content, instead of embedding them, we allow topics to be more flexible in their reuse. We can add context and applicability without impacting the existing uses for that content.
Obviously this doesn’t work for all customers.
Aerospace and defense customers who are required to provide their content in S1000D and similar compliant XML structures will always have metadata- and attribute-heavy authoring processes.
Tech pubs groups who produce online documents that are interactive are dependent on metadata and attributes in the XML to drive the appropriate display of document content, but in future, they may want to consider pushing that classification into the final output of the technical publications software, instead of imposing that work on the writers up front.