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

Looks good with me. I like the idea of having no prefixes but I have no
doubts that one day two vocabularies will run into homonyms and we have to
have mechanism to resolve it. As alternative to "mycocab-myrole" approach
it may be reasonable to have separate @vocab attribute defined in the
context tree to help to resolve ambiguity.
Thanks.
Alexander.

On Thu, Apr 16, 2015 at 11:11 AM, Shane McCarron <shane@aptest.com> wrote:

> 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.
>