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

Gregg Vanderheiden gv at trace.wisc.edu
Thu Feb 9 22:50:13 UTC 2012


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120209/1c3b824f/attachment.html>


More information about the Accessforall mailing list