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

Liddy Nevile liddy at sunriseresearch.org
Thu Feb 9 21:18:27 UTC 2012


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



More information about the Accessforall mailing list