OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita-help message

[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?

Topic file name abstracted from context hook?

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?

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]