<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">yep<div>this is similar to what we are doing.</div><div>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). </div><div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><i>Gregg</i><br><div>--------------------------------------------------------<br>Gregg Vanderheiden Ph.D.<br>Director Trace R&D Center<br>Professor Industrial & Systems Engineering<br>and Biomedical Engineering<br>University of Wisconsin-Madison<br></div><br>Co-Director, Raising the Floor - International<br>and the Global Public Inclusive Infrastructure Project<br><a href="http://Raisingthefloor.org">http://Raisingthefloor.org</a>   ---   <a href="http://GPII.net">http://GPII.net</a></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br></div></span></div></span></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br><div><div>On Feb 9, 2012, at 3:18 PM, Liddy Nevile wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>thanks for this!<br>I think I get tags...<br><br>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.<br><br>Liddy<br><br>On 10/02/2012, at 6:14 AM, Gregg Vanderheiden wrote:<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Feb 9, 2012, at 10:54 AM, Clark, Colin wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Hi Greg,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Responses inline...<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On 2012-02-09, at 12:38 AM, Gregg Vanderheiden wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">different topics<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">one has to do with the same preference appearing in multiple times in a hierarch and having to be maintained there.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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<br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite">2) they could be tokenized  or compressed (which will tokenize them)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">so no problem for using URLs<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Again - there can even be different TAG sets - reflecting different models of the world.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Lets chat.   Tags are mostly used to find things.   Like keywords for documents.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">"show me all the preferences for people who are BLIND or   have COGNITIVE DISABILITIES   or   are DEAF"<br></blockquote><blockquote type="cite">"show me all the preferences that relate to SCREEN READERS"<br></blockquote><blockquote type="cite">"show me all the preferences that relate to VOICE SYNTHESIZERS<br></blockquote><blockquote type="cite">"show me all the preferences that relate to TEXT COMMUNICATION<br></blockquote><blockquote type="cite">"show me all the preferences that relate to CAPTIONS<br></blockquote><blockquote type="cite">"show me all the preferences that relate to<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">GV:  what is your alternative that would provide guaranteed unique?<br></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">absolutely no need for anything to be unique except     preferenceRef:source<br></blockquote><blockquote type="cite">since we may want translations, I would make the PreferenceRef a number so it becomes     PrefNumber:RegistryID<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">a registry entry would be would have a unique identifier of<br></blockquote><blockquote type="cite">PrefNumber:RegistryID<br></blockquote><blockquote type="cite">and values of     ValueType, ValueRange<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">A separate file can contain names so that it can be localized.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Another file can contain the tags or outlines - so that different ones can be proposed.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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" (<a href="http://en.wikipedia.org/wiki/Don%27t_repeat_yourself">http://en.wikipedia.org/wiki/Don%27t_repeat_yourself</a>) is a very useful principle we can apply to our specification.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I don't quite understand what you're suggesting, but it sounds vaguely reminiscent of what I'm proposing.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">just a way to not repeat a very long string 99 times.  you just create a token for the phrase.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">(won't we send as compressed - and this is what the compression routine will do automatically )<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">agree<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">---<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Colin Clark<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Lead Software Architect,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Inclusive Design Research Centre, OCAD University<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://inclusivedesign.ca">http://inclusivedesign.ca</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Accessforall mailing list<br></blockquote><blockquote type="cite"><a href="mailto:Accessforall@fluidproject.org">Accessforall@fluidproject.org</a><br></blockquote><blockquote type="cite"><a href="http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall">http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall</a><br></blockquote><br>_______________________________________________<br>Accessforall mailing list<br><a href="mailto:Accessforall@fluidproject.org">Accessforall@fluidproject.org</a><br>http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall<br></div></blockquote></div><br></div></body></html>