dita — archive

[Eliot Kimber]

In the process of working through the 1.2 issues for which I'm a champion of record, it started to occur to me that we're getting a bit ahead of ourselves, in that most, if not all the issues as written are presented as proposals for specific functionality. But what we really need first are agreed-upon statements of requirement, from which we can then identify specific features that would satisfy those requirements and then, from that, specific implementations of those features. That is, in an engineering activity, I would not normally accept an implementation proposal before I had a clear and accepted statement of the requirements that implementation claims to satisfy. I would like to propose that we, the champions of each proposal, take the time to write up a clear, implementation-neutral, statements of requirement for their issues. For many proposals the proposal itself will not change but it will be much clearer what the requirement is. But for some it may make it easier for us, as a group, to evaluate the requirements on their merits and then more clearly and productively formulate proposals for satisfying those requirements, where the existing proposal is either underspecified, non-existent, or controversial. To take a simple example, my issue 12022, Make @role unenumerated, can be restated as a requirement like so: "Authors and specialization designers should be able to specify arbitrary values for the role= attribute of link elements." Given an acceptance of that requirement, the implementation solution is obviously "make @role unenumerated". But there could be other reasons for making rule unenumerated that have nothing to do with the needs of authors, so just stating the implementation is not sufficient to unambiguously indicate the driving requirement. At a minimum, this will validate that the champions of the different issues have sufficient understanding of them to clearly state the requirements implicit or explicit in them. Note too that there may be more than one feature resulting from a single requirement, depending on the nature of the requirement and how it interacts with existing DITA functionality and design principles. Cheers, Eliot -- W. Eliot Kimber Professional Services Innodata Isogen 8500 N. Mopac, Suite 402 Austin, TX 78759 (214) 954-5198 ekimber@innodata-isogen.com www.innodata-isogen.com