- From: Alexander Surkov <surkov.alexander@gmail.com>
- Date: Mon, 27 Apr 2015 13:49:49 -0400
- To: Shane McCarron <shane@aptest.com>
- Cc: "W3C WAI Protocols & Formats" <public-pfwg@w3.org>, Protocols and Formats Working Group WG <w3c-wai-pf@w3.org>, "public-dpub-aria@w3.org" <public-dpub-aria@w3.org>
- Message-ID: <CA+epNse9fVy=_gcfS+N0wdQ0KpssyEM6tU_PMdbh=392dJwzhQ@mail.gmail.com>
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. >
Received on Monday, 27 April 2015 17:50:17 UTC