Proposal for New <context-help> Element
Self on Help
Thoughts from the OASIS DITA Help Subcommittee Chair
The DITA Help Subcommittee is discussing a proposal to create a new <help-context> element to hold metadata required for context-sensitive Help. The proposal would see the new element fit under the <topicmeta> element in the ditamap, and/or in the <prolog> element in the topic. The element would hold context numbers and/or context strings, and/or a reference to a window description. (There would need to be a separate element in the ditamap that would store the characteristics of a window named in the context-help element.)
In addition to this approach of storing context hooks in the DITA content, it would still be possible, under an associated proposal, to store context hooks in a separate file externally from the DITA source. How that would work is the next problem to tackle!
Search
Recent Content
- Forum for DITA Users
39 weeks ago - Publishing for DITA
5 years ago - Optimizing the DITA Authoring Experience — Online Course
5 years ago - Linking to another chunked topic
5 years ago - Advanced Reuse Strategies — Online Course
5 years ago - 2019 Content Management Strategies/DITA North America Conference
5 years ago
Subscribe
contexthelp=resourceid?
I'm assuming this would be specialized from resourceid, which is designed for this purpose?
In terms of defining the ids separately from the DITA source, I'm not sure I understand the requirement. Isn't the DITA map already providing this separation? If you need a third level of indirection, would keyref fit the bill?
Michael Priestley
Context hooks
Sorry for missing your reply for six months, Michael!
We think there are four scenarios for the creation and maintenance of context hooks. These are described at:
http://wiki.oasis-open.org/dita/Implementation_Scenarios
The need for the IDs to be maintained outside DITA might be driven by the way the programming environment works, the way the program team works, or there being mixed sources for the Help (some from DITA, some from elsewhere). As an example, a programming control might allows the Help author to "collect" the mapping relationships by running the app in "authoring mode", with the "unmapped" Help file in situ, to generate a map file. Rather than re-entering the map ids into the ditamap, it would be desirable to just select the generated map file during the DITA build process.
The keyref attribute might be used to store the location of the indirected map file, although is some cases there may be two files (eg, HTML Help context hooks are stored in a map AND an alias file). Logically, this would be stored in the map element, and I don't think @keyref is valid there.
The resourceid element could probably be specialised to contexthelp, provided resourceid could also remain in the model in case it was needed too.
Tony