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

Andy Heath andyheath at axelrod.plus.com
Fri Feb 10 00:05:07 UTC 2012


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

One question. Should we say URI rather than URL so as to allow other 
kinds of identifier ?  If we were talking about content then use cases 
for use of URI's as identifiers are legion. I can't think of a case 
where a registered preference would need to be a URI but not a URL - I'm 
just asking if anyone can.  The others I'm fine with, though  there is 
work to determine exactly what 8. means in practice.

andy
>
>
>  1. The registry will contain a flat structure,
>  2. URLs are fine namespaces.
>  3. What is supposed to be read by machines should be easy for machines
>     to read
>  4. What is supposed to be read by humans should be easy for humans to read
>  5. The website and its presentation of the /*Needs & Preferences
>     Registry */should be user friendly.
>  6. The preference profiles and preferences themselves as read by the
>     machines should be easy for machines to read and process.
>  7. 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.
>  8. 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.
>  9. Nothing in the ISO 24751 or AccessForAll standard should prevent
>     implementations or anything else from representing using
>     hierarchical (or any other) data structures, I
> 10. 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.
> 11. 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.
> 12. 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.
>
>
>
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall



Cheers

andy
-- 
__________________
Andy Heath
http://axelafa.com



More information about the Accessforall mailing list