[Accessforall] Minutes of AccessForAll Meeting on 2012-01-31

Liddy Nevile liddy at sunriseresearch.org
Thu Feb 9 23:50:46 UTC 2012


looks good to me...
Liddy

On 10/02/2012, at 9:50 AM, Gregg Vanderheiden wrote:

> Great summary Colin.
> I added a couple statement from others -- and numbered them for ease  
> in reference.
>
> Lets see where we agree and if there are any disagreements
>
> So does anyone have a problem with any of these statements?   Or  
> suggestions to tune them  (these are basic statements so should be  
> simple -- including only IMPORTANT caveats)
>
>
> 	• The registry will contain a flat structure,
> 	• URLs are fine namespaces.
> 	• What is supposed to be read by machines should be easy for  
> machines to read
> 	• What is supposed to be read by humans should be easy for humans  
> to read
> 	• The website and its presentation of the Needs & Preferences  
> Registry should be user friendly.
> 	• The preference profiles and preferences themselves as read by the  
> machines should be easy for machines to read and process.
> 	• The specific mechanism for representing the namespace is an  
> implementation-specific detail. In XML, they'll be represented using  
> colons and the xmlns attribute, and in other formats they may be  
> represented differently.
> 	• It should be possible for implementations or presentations of the  
> Needs & Preferences Registry Entries  to be presented flat,  
> hierarchically or in other formats to aid in viewing but no  
> particular view should be required by the structure.
> 	• Nothing in the ISO 24751 or AccessForAll standard should prevent  
> implementations or anything else from representing using  
> hierarchical (or any other) data structures, I
> 	• Tags on the registry items are not part of the registry items and  
> would not be part of preferences profiles.They're a tool (for use on  
> our web site or elsewhere)  to enable users to sort, search, and  
> view the registry's content.
> 	• Tags are NOT PART OF the registry items but associated with  
> them.   RtF will maintain one set based on the GPII workgroup input  
> for use on the RtF/GPII site.
> 	• But there COULD be other sets of TAGS generated by other people  
> that would organize and present the registry entries differently on  
> other web sites.   The tags could also be constructed so that they  
> would create a Hierarchical presentation of the registry items.  But  
> again - that is a presentation of the items. The items themselves  
> stand alone as items in a flat registry.
>
>
>
>
>
>
>
> On Feb 9, 2012, at 4:12 PM, Clark, Colin wrote:
>
>> Hi All,
>>
>> And from my end, I had a minor epiphany while on the subway this  
>> morning that helps me join the violent agreement. Here's a summary:
>>
>> * Gottfried's proposal fully makes sense to me now, and I agree  
>> with it. The registry will contain a flat structure, and URLs are  
>> fine namespaces.
>> * Unlike the UIC example we've been bouncing around, our website  
>> and registry should be more user friendly. As Liddy says, URL are  
>> for machines, words are for people. We'll just need to design a  
>> better interface for the registry.
>> * The specific mechanism for representing the namespace is an  
>> implementation-specific detail. In XML, they'll be represented  
>> using colons and the xmlns attribute, and in other formats they may  
>> be represented differently.
>> * As long as nothing in the standard prevents implementations from  
>> representing ISO 24751 using hierarchical (or any other) data  
>> structures, I'm fine with whatever structure we like within the  
>> specification and registry. Flat is a-okay.
>> Gregg and I chatted further on the phone about his tags idea, and  
>> he clarified that the tags were only designed for the registry  
>> system itself, not part of the preferences profile. In other words,  
>> they're a tool on our website to enable users to sort, search, and  
>> view the registry's content. Sounds good to me.
>



More information about the Accessforall mailing list