[Accessforall] Minutes of AccessForAll Meeting on 2012-01-31
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.
> 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
>> * 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
More information about the Accessforall