Notes on the state of the art

Questions

is the DITA conceptual space adeguate ? \ ANSWER: probability it is a very good starting point, but it is not completely adeguate to achieve the objective to create (also in a dynamic way) a version of the manual related to the specific needs of the reader Moreover, DITA seems to be extensible; but it is not clear if any extension can be formally modeled and supported by tools automatically generated form the model

does a IBM working gruop introduce new concepts (with respect to the DITA space) to build a manual? if yes, what are these concepts? \ ANSWER: it seems so; examples could be the concept of manual type, person, task cathegory (if any) etc.

the new concepts currebtly used in IBM could be introduced in DITA? \ ANSWER: ??

If yes, why they are not?\ ANSWER: perhaps for problems of costs related to the building of new editing tools

how are the different DITA tiplogies of topics (concept, task, reference) used? ANSWER: the point is not clear; from the example we infer that they are not used (e.g. the step tag of the task seems to generate only an item in an index HTML)

the production prcess of a manual is content driven? \ ANSWER: it seems so; i.e. the focus seems to be on the best way to define contents, not on on the best way to organize contents in order to give the reader the opportunity to naviagate (read) according to his/her needs (the concept of "manual type" could be an exception to this rule)

do we agree that

  • a DITAmap file provide a default navigation (hyerarchiclal) index; one map => one manual

  • a DITA manual is something to read, not something to work with (also for the task topic

    )
  • we (still) do not have a (full) DITA interpreter (assumed that DITA defines a standard behavioral semantics) ; the manual viewer is actually at most a conventional browser (without any javascript "DITA interpreter")
  • ... 

ANSWER: we should discuss

is the manual concevied as a single entity (according to a model view approach)? \ ANSWER: perhpas no; it seems that one single software product will lead to several manual types, each produced in an independent way (an exception could be the procees of producing different versions of ??? for the tivoli provisioning manager, for the orchestrator, etc)

it is better to produce manuals as different versions of a single knowledge base (file content set) or spli the production into difeerent subprojects (e.g. one for each manual type)? \ ANSWER: the monolitic approach should be better for assuring consistency, but could introduce difficulties related to cooperting working among people.

\ what is the main goal: to exploit DITA or to make the manual reader an active system? \ ANSWER: perhaps both of them

should the manual production begin during the software process documentation? \ ANSWER: perhaps yes

\ \
\ \