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

Gregg Vanderheiden gv at trace.wisc.edu
Thu Feb 9 19:14:56 UTC 2012



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
> 



More information about the Accessforall mailing list