[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Retrospectively Checking Requirements
Dear All When we discussed (through this list) the broad requirements for context-sensitivity, a number of good ideas and suggestions were put forward. Now that we've got some sort of proposed structure for context strings, I thought I'd go back through the previous discussion to make sure the proposal fits the requirements. Cope with programmer supplying context numbers? Yes, assuming a tool is developed to allow mapping of header file to ditamap topicrefs. One context number to many topics? Possible (though why?) One topic referenced by many context numbers? Yes Topic file name abstracted from context hook? Yes Context number restrained to be unique? No. How could this be enforced in a modular architecture? Any context id attribute is separate from the element's unique id attribute? Yes Allows for four strategies: . 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 domain element Yes to the first two (except prolog and topicmeta). Doesn't exclude the third. Doesn't address the fourth. Context hook could be re-used? Yes, if help elements can be "conreffed". Context hooks can be filtered? No, but could do so if metadata attributes were added to the proposed <help> (or context-help) element. Are there other issues that I've missed? Tony Self
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]