Hi Su-Laine --
In terms of what is or is not appropriate procedurally for DITA Technical Committee approval of a DITA Subcommittee (SC) document, I defer entirely to the TC Chair, the TC, and OASIS.
In terms of this proposed subcommittee publication and others in the pipeline (preceding and following), I can provide some context ... at least from my perspective. :-)
Subcommittees should seek approval from their parent TC(s) before they publish documents for at least three reasons:
1.
Sanity check -- Does this proposed publication conform to the goals of the
subcommittee? Is it appropriate?
2.
Sanity check -- Does the proposed publication offer value to the target
community? In this case our audience consists of Help authors who use
DITA as their source.
3.
Endorsement -- Does the proposed publication reflect positively on the
overall mission of the TC? Would members of the TC promote this
publication in their respective organizations?
The DITA Help SC has updated the TC on its proposed DITA 1.2 and DITA 1.3 goals and activities numerous times:
- DITA 1.2:
> Get organized
> Survey the state of DITA-authored Help
> Educate DITA users about existing solutions (this publication)
- DITA 1.3:
> Continue to educate folks about existing solutions
> Identify and develop specializations and custom processing
that would advance the feature set and usability of
DITA-authored Help.
Before your email last evening, all the feedback that I have received has been supportive of the content in the
DITA Help Technologies Guide and of approving it at our TC meeting today. There are a couple of nice-to-have production edits and nice-to-do build improvements (notably DITA 1.2 and DITA-OT1.5 M11), but otherwise what is before the TC represents the best effort of the Help Subcommittee. I continue to recommend that we discuss and approve it today.
Thanx,
Stan