Retrospectively Checking Requirements

["Tony Self" <tself@hyperwrite.com>]

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