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

Gregg Vanderheiden gv at trace.wisc.edu
Thu Feb 9 21:21:32 UTC 2012


yep
this is similar to what we are doing.
like to be able to handle localization though-- and not have to freeze the english names.  so I suggest the base reference not be human language.   but all viewing of them by humans is human language (label paired with stable non-language based unique code). 

Gregg
--------------------------------------------------------
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison

Co-Director, Raising the Floor - International
and the Global Public Inclusive Infrastructure Project
http://Raisingthefloor.org   ---   http://GPII.net








On Feb 9, 2012, at 3:18 PM, Liddy Nevile wrote:

> thanks for this!
> I think I get tags...
> 
> The usual way to handle the URIs is to have namespaces that are identified and then a prefix (eg AFA) is used so the individual terms are found in the relevant namespace. I am not sure why there is a problem - if the pairs have words those can appear in the code - AFA:textsize - for example would send a machine to a namespace identified by AFA and the human can see what's happening.
> 
> Liddy
> 
> On 10/02/2012, at 6:14 AM, Gregg Vanderheiden wrote:
> 
>> 
>> 
>> On Feb 9, 2012, at 10:54 AM, Clark, Colin wrote:
>> 
>>> Hi Greg,
>>> 
>>> Responses inline...
>>> 
>>> On 2012-02-09, at 12:38 AM, Gregg Vanderheiden wrote:
>>>> GV:   I think hierarchy is a problem -- since many preferences will end up in more than one parent -- with either Aliasing or duplicating (with the problem of maintaining) can be a problem.
>>> 
>>> So here you're arguing that duplication is a problem for hierarchies, but in the case of redundantly prefixing each and every property in a preferences profile with a long URL, you don't think duplication is a problem?
>> 
>> 
>> different topics
>> 
>> one has to do with the same preference appearing in multiple times in a hierarch and having to be maintained there.
>> 
>> the other has to do with a long string of characters that keeps appearing for each (different) preference belonging to the same origin.   it is a file length problem only.    but as I pointed out below - I don't think that it is a problem because
>> 1) any file viewer could lay things out so that those were in a separate 'column' and easy to ignore (or they could be put AFTER the name - value pair on the display to make it easy for screen readers to ignore them by moving on to the next line  -- or having them hidden.
>> 2) they could be tokenized  or compressed (which will tokenize them)
>> 
>> so no problem for using URLs
>> 
>>> 
>>>> My personal belief is that we should use TAGS rather than categories.   It is easy to find all of the preferences that relate to any TAG and a preference could have many different tags.
>>>> 
>>>> Again - there can even be different TAG sets - reflecting different models of the world.
>>> 
>>> Tags are a really cool idea. Gregg, can you take a stab at showing how you'd represent tags using the "simple data structures" we all favour? (hint: you'll need containment)
>>> 
>>> Also, it's worth trying to sketch out the algorithm we'd propose to implementors for parsing tags and matching them to categories of assistive technologies. Gregg, do you want to take a stab at that? It's likely a more complex algorithm than traversing a straight hierarchy, but it might well be a worthwhile approach.
>> 
>> Lets chat.   Tags are mostly used to find things.   Like keywords for documents.
>> 
>> "show me all the preferences for people who are BLIND or   have COGNITIVE DISABILITIES   or   are DEAF"
>> "show me all the preferences that relate to SCREEN READERS"
>> "show me all the preferences that relate to VOICE SYNTHESIZERS
>> "show me all the preferences that relate to TEXT COMMUNICATION
>> "show me all the preferences that relate to CAPTIONS
>> "show me all the preferences that relate to
>> 
>>> 
>>>>> 1. They're easy for machines, but are hard for people to read. We want our specification to be as approachable and easy-to-understand as possible. Using URLs instead of readable names increases complexity; when I read through the UIC spec, I found it a bit intimidating.
>>>> 
>>>> GV:  what is your alternative that would provide guaranteed unique?
>> 
>> absolutely no need for anything to be unique except     preferenceRef:source
>> since we may want translations, I would make the PreferenceRef a number so it becomes     PrefNumber:RegistryID
>> 
>> 
>> a registry entry would be would have a unique identifier of
>> PrefNumber:RegistryID
>> and values of     ValueType, ValueRange
>> 
>> A separate file can contain names so that it can be localized.
>> 
>> Another file can contain the tags or outlines - so that different ones can be proposed.
>> 
>> 
>>> 
>>> As I said in my previous email, I'm proposing the optional inclusion of a unique namespace housed at the top of a collection of preferences to which the namespace applies. It's easy for implementers to handle, simple to express, and doesn't repeat itself.
>>> 
>>>>> 2. Prepending a namespace (URI) to each and every key will have a substantial performance impact on real-world implementations. Remember that in many applications, the user's profile will be sent across the network and may be processed and transformed multiple times. For Cloud4all, we're anticipating supporting mobile devices and global deployments; sending redundant data across slow connections (like a mobile phone's EDGE connection) will be a bottleneck. "Don't Repeat Yourself" (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself) is a very useful principle we can apply to our specification.
>>>> 
>>>> GV:  I agree - but couldn’t you handle this with a token / variable at the top for any URI/URL that is repeated in the string?
>>> 
>>> I don't quite understand what you're suggesting, but it sounds vaguely reminiscent of what I'm proposing.
>> 
>> just a way to not repeat a very long string 99 times.  you just create a token for the phrase.
>> 
>> 
>>> 
>>>> (won't we send as compressed - and this is what the compression routine will do automatically )
>>> 
>>> Perhaps, but that's an implementation detail. A specification shouldn't force implementors into a particular performance optimization in order to work around its weaknesses.
>> 
>> 
>> agree
>>> 
>>> 
>>> ---
>>> Colin Clark
>>> Lead Software Architect,
>>> Inclusive Design Research Centre, OCAD University
>>> http://inclusivedesign.ca
>>> 
>> 
>> _______________________________________________
>> Accessforall mailing list
>> Accessforall at fluidproject.org
>> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall
> 
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall

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


More information about the Accessforall mailing list