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

Alexander,

Thanks for your note.  The Role Attribute recommendation [1] actually
already takes into account the ability to have multiple vocabularies for
the role attribute.  Role is a part of the RDFa [2] universe, and as such
is supposed to take into account @vocab.  In reality this is not (yet) the
case for HTML 5 but I hope that eventually we will get to that point.

[1] http://www.w3.org/TR/role-attribute/
[2] http://www.w3.org/TR/rdfa-core/

On Mon, Apr 27, 2015 at 12:49 PM, Alexander Surkov <
surkov.alexander@gmail.com> wrote:

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


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