[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Managing "contextless elements" as for L&T Assessments and Objectives
Rob’s example of figures brought to mind a kind of “contextless element” case that I dealt with previously. As it’s a non-L&T case, it might be interesting to consider in the general case of whether such an architectural feature is needed. A client had topics in which most of the content applied across a range of products. However, towards the end of each of these topics (i.e. before the next heading), there would be a detailed drawing and callout descriptions that were specific
to just one of those products. Clearly, fig was the right element to use, with a nested image and a descriptive list or table. However, they needed a way to swap out the figs for the particular context, keeping the rest of the topic generic. Of the standard
options:
What we did in the end was something a little unorthodox. In fact, I have had a little pushback on it since a new team came in with DITA purity as a primary focus. So I’m quite reassured that Rob and Eliot have mentioned usages along similar
lines. ☺ The clients’ CMS had a really nice UI for managing maps and topics. So we decided to manage the variable fig elements in dedicated topics. However, we didn’t need or want to display the title of those fig-only topics in output. It was the
title element of the fig itself that should be displayed, and used for lists of figures, cross-references, etc. So we did what Rob described — used the topic title as a label for internal management purposes only, and suppressed it in output. We defined a
new topic shell for this purpose so authors and stylesheets alike could be clear what the effect should be. This mechanism did the job, although given that the CMS now supports conkeyref much better, and the new authoring team are more comfortable with some of the more complex but standard ways of working in DITA, if I were to approach the same
situation now I might just suggest conkeyref. Back to Eliot’s original post, I would like to hear a bit more about the usability problems of conref / conkeyref for the L&T questions. There are certain CMSs that encourage people to define conreffable elements in separate topics anyway,
which I would have thought could work well for this case. Is it just the unwanted title elements that are the problem? Cheers, Joe — Joe Pairman | Mekon | Tel: +44-7739-522002 | Mobile: +44-7472-745-063 | Skype: joepairman From: <dita@lists.oasis-open.org> on behalf of Amber Swope <amber@ditastrategies.com> Thanks for the notes, Rob and David. Many companies need to manage questions a separate units, which means that the easiest way to assemble them in a deliverable is to have separate topics and then organize them with a map. This also allows you
to apply different key value to different questions in the context of a map. The L&T SC has determined that storing the questions as separate units is a requirement we need to support.
As for the title discussion, I have not yet seen question title used for a publishing context. One could argue that the question stem may be relevant as a label for the topic, but question stems may be more than
one paragraph and may be very generic. The real issue is that most folks don’t have anything to use as a label for a given question. So, I have been considering this challenge from the perspective of how folks use the topics.
One of the primary use cases is assembling a collection of questions for a test. Because it is very common to have the same stem for multiple questions, the current out-of-the-box support in most editors is to
display the title for the topic reference. This means that if you leave the title blank in the question topic, then the map is a list of nameless topic references. You essentially have to use a view with the resolved topics to know what you’re building. In
many cases the order of the references isn’t important, but you need to know that you haven’t included the same question multiple times. You may also need to apply key references to specific questions so it is imperative that you know which question is referenced. For example, for a driver training course, you may have 500 topics with “Who has the right of way in the following traffic pattern?” as the question stem. What would be the label or title for these topics? If
I’m assembling a map to test the learner’s knowledge about the concept of right of way, I could have 50 of these question in a map. To associate the relevant learning objective to the topic, I need to know which questions apply to which learning objective.
When I consider the role that a title plays in this scenario, the issue is about what is displayed in the map rather than what is stored in the topic. I can think of several options to help with the display of
relevant metadata is helpful, but none of them address the question of what, if anything, should be stored as the title or label of a question. Eliot proposed three options in the original email. Although an option, I don’t support the idea to directly use elements in the map. I’d like to investigate the first two options and any others that folks can
propose. If you have other options, please contribute your suggestions. Have a great day, Amber From:
dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org]
On Behalf Of Rob Hanna While there are admittedly topic types where the title is not required for publishing, I think that every topic needs a label for identification and management purposes. The title plays a dual role as content and metadata
(label). Could the solution be as easy as specializing a label element from title from some topic types where this is the case? I think label could be a useful substitution for title in any instance where the title is not needed for publication but still required
for identification, such as sections and figures. Cheers, Rob Hanna From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org]
On Behalf Of David Hollis Hi Amber, Eliot, Isn't the generic DITA topic already quite "contextless"? I thought that chunking was the way to use a topic without the title? I assume there is a title somewhere, just it is not required for the "contextless" topic. This seems like a parallel to Information mapping? I would be concerned if the proposed solution would be to put content in a map, and would suggest a wider discussion about what the role of a map and a topic should be, going forward. I appreciate that metadata in a map is already used
for various purposes: reuse and subject schemes, for instance. But one of the potential solutions would seem to go further than that. I acknowledge Eliot's caveats about this potential solution. There might be a parallel with resource-only "container topics", or "warehouse topics" that simply provide content for reuse. The topic itself never appears in the final document. My two penn'orth. HTH, David
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]