Re: [dita-help] Context-Sensitivity

[Alan Houser <arh@groupwellesley.com>]

I must admit that I'm still getting my head around these issues, but 
wanted to raise a possibility.

Assuming that "hook" == "unique identifier", we already have a 
persistent ID in each topic, and can specify an ID value on virtually 
every DITA element. Is there a reason that we would not leverage these 
IDs as hooks?

For the mappings, I view defining CS mappings in the same category as 
defining a one-to-one relation table -- invariant topic/element IDs 
(hooks) to GUI identifiers.

I must admit that I'm cautious about the complexity and implementation 
issues that may arise from supporting hooks in both topics and maps. I'm 
also concerned about supporting variant "hooks" within topics and even 
maps. I think these should be invariant, with an external mapping file 
(possibly DITA, XML, or text-format) used to define relationships that 
are particular to a specific help deliverable.

Of course, topic IDs may not be author-friendly. But it would be easy to 
generate reports that present lists of topic IDs and their corresponding 
topic file names and/or topic titles. It should also be relatively 
straight-forward for vendors to incorporate this information into DITA 
editors.

I may be all wet, or I may be missing something.

-Alan
---

Alan Houser, President
Group Wellesley, Inc.
412-363-3481
www.groupwellesley.com



Stan Doherty wrote:
> Good stuff ... here's some friendly additions/qualifications:
>
> . context hooks stored in the [individual] topic [prolog?]
> . context hooks stored in the [individual] map [prolog?]
> . context hooks stored in an [unstructured]  intermediate (external) file
> . context hooks stored in a specialized  DITA topic or specialized 
> domain element
>
>
> Rationale ... we should explicitly add the option of a DITA-parseable 
> topic or element that contains CS hooks that could be reused, 
> filtered, or transformed across multiple projects. At Sun we do a lot 
> of weird, one-off help development, so the ability to process 
> callbacks without leaving the DITA parsing environment would be cool 
> ... parsing callbacks using the same logic that we use to process 
> regular DITA elements via .ditaval settings would be a plus.
>
> Stan
>
> P.S. I have a 1:30PM/EST meeting offsite and will make every effort to 
> make it back to my office or to home by 4:30PM/EST for our concall.
>
> Tony Self wrote:
>> Dear All
>>  
>> Would it be right to summarise the CS requirement by saying that we 
>> need to provide for three options?
>>
>> . context hooks stored in the topic
>> . context hooks stored in the map
>> . context hooks stored in an intermediate (external) file
>>
>> During processing, the necessary map/alias/header/cshelp files would 
>> be produced from whatever resource was available.
>>
>> There would need to be some rules to cope with hooks found in more 
>> than one location. For example, if there was a hook in the map's 
>> topicref and the topic, which hook would be used. I would suggest 
>> that both would be valid. But is that logical? Maybe we need a 
>> "cascade":
>>
>> . Context Hook in intermediate (external) file overrides...
>> . any context hook specified in the map, which overrides...
>> . any context hook specified in the topic.
>>
>> Thoughts?
>>
>> Tony
>>
>>
>