There is a lot happening in this thread that I
want to respond to:
- One reason that I advocated that we review
the "complete" (base + technical content + learning & training)
version of the 1.2 specification was to ensure that we considered
whether or not the three sections of the architectural spec were
parallel in tone, content, audience, etc. I was aware that the learning
& training material had a very different organization and style
than the other material.
- We previously took time to explore the
question of "Who is the audience for the architectural spec topics?,"
and came to the following consensus:
The
intended audience of the architectural
specification is not a typical author or end user; the intended
audience
is people designing tools that work with DITA. Such people need to
understand
how the core elements of the DITA architecture work together. While the
architectural specification is not intended to provide step-by-step
instructions,
it needs to contain enough topics that describe the overall flow, so
that
tools vendors 1) will understand how people will use DITA, and 2) will
be able to properly implement the standard as intended ("spirit not
just letter of the law.")
For more information, see
http://wiki.oasis-open.org/dita/DITA_1.2_specifications:_Authoring_and_editorial_guidelines#Audienceandpurposeforthearchitecturalspec
- We need
to write the specification in a way that is technically precise and
reflects common vocabulary established by the XML standard. At the same
time, given DITA's origins, we need to be aware of the terminology and
assumptions that technical communicators and single-sourcing advocates
bring to the table.
I think good old-fashioned technical writing and
editing will go far to handle the problem. Yes, that takes time and
skill, but we do have people on the TC with expertise in this area.
Best,
Kris
|