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

Clark, Colin cclark at ocadu.ca
Thu Feb 9 16:54:09 UTC 2012


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?

> 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.

>> 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?  

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.

> (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.

>> Could we instead consider a model where preferences can be stored in "buckets," each of which may optionally have a namespace associated with it? Here's a few examples of what I'm thinking of; I'm using JSON syntax (http://www.json.org/fatfree.html) because it's simple, but this should work in any representation.
> 
> GV:  interesting - but if they are all distributed -- and the same term is used by different buckets... would it result in the same or similar?  

I'm sorry, I don't quite understand the question. Can you try asking it in a different way?

Colin

---
Colin Clark
Lead Software Architect,
Inclusive Design Research Centre, OCAD University
http://inclusivedesign.ca



More information about the Accessforall mailing list