Extension specifications / modules vs. ARIA Core (ACTION-1618)

Folks,

(Apologies for the CC list.  PF's issue tracker only monitors the
non-public list.)

This came up again today in the DPub call.  I would like to have the PFWG
take some time on an upcoming agenda to formally resolve how modules are
developed and how those modules relate to the core document(s).  In order
to get the discussion started, I propose that we adopt the HTML Working
Group's model for Extension specifications as a basis [1].  My translation
of their rules into our context would be:

   1. Anyone can start working on an extension / module.
   2. At some point an extension should be exposed to the broader (ARIA)
   community for socialization / comment / approval.
   3. If the community ultimately finds an extension interesting, it can be
   formalized and merged into the core spec or left as an independent
   specification.
   4. In either case, if an extension eventually becomes (part of) a W3C
   Recommendation, then it's normative non-optional components are required
   for *every* conforming implementation (hand-wave about versions and
   synchronization - TBD).
   5. The earlier a group starts coordinating with the PFWG in their
   development process, the more likely it is that there will be a smooth
   transition into the W3C and its Recommendation Track.  However, there is no
   guarantee this will happen.

>From a technical perspective I would propose:

   1. Acceptable extensions MUST conform to and MAY extend the existing
   taxonomy.
   2. Any new roles MUST be a descendant of a role or roles in the ARIA
   Core. To promote faster adoption, new roles SHOULD be a descendant of a
   role or roles in the current ARIA Core W3C Recommendation (as opposed to a
   future version of that Recommendation).
   3. Any new states or properties MUST be very carefully coordinated with
   the ARIA Core development group as well as user agent and AT implementors.
   4. Roles/State/Properties that are named in a scoped manner
   (myvocab-myrole) are more easily adopted than ones that are in an unscoped
   space (myrole).
   5. Extension specification developers are responsible for providing the
   specification, use cases, and conformance tests.

Opinions?

[1] http://www.w3.org/html/wg/wiki/ExtensionHowTo

-- 
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.