[Accessforall] Conditional preferences

Andy Heath andyheath at axelrod.plus.com
Sun Aug 5 10:02:14 UTC 2012


Hi HdM:Andy and Colin,

I had a look at your suggested changes Colin, here

http://wiki.gpii.net/index.php/Simplifying_Preferences_Documents

Some comments from a non-json expert (me) :

1. With respect to the first one, "preferences being indexed by term name",
the issue with the gathering of values that go with repeated keys as I 
see it (and it may not be an issue - I'm not an expert with *using* 
json), is the extra complexity and the fact that we have two different 
ways to code a single preference (unless one does the array structure
for every unique preference key even if there's only one value in it).
The reason this comes up for me is in AfA 3 I reckon we're going to
have to map XML and json together so I was looking at the ways to do 
that and an unambiguous representation (i.e. only *one* way to do it) 
seems to simplify that and what one might have to do with the result. 
I'm very happy to be corrected by an expert in both json and xml parsing 
here.

2. The escaping and the empty fields thing seem eminently sensible.

3. For the URL thing - making it more readable - I'm not sure that
introducing structure in the way you have makes it more readable - in 
fact it makes it more complex to understand as a human (which matters
until we have tools to easily edit it etc.).  However, since it seems
that in some technologies there will be a need to map XML bindings of
stuff and the JSON prefs together (e.g. consider how one might do
dynamic ajax content swapping with content having embedded XML metadata 
(as documents might well have)) - then how about we make that easy by
effectively implementing namespaces in json - for example like this

[ {"xmlns" : { "fontsize" : "http://gpii.net/ns/up/fontsize",
              "speechrate" : "http://gpii.net/ns/up/speechRate" } },
   [ {
     "property": "speechRate",
     "condition": "",
     "value": 90
     },
     { "property": "fontsize",
       "condition": "",
       "value": "120%"
     }
   ]
]

Missing field names works quite well. Alternatively, pull the
field names into a list out front and use null for properties
where we have no value - for example:

[ {"xmlns" : { "fontsize" : "http://gpii.net/ns/up/fontsize",
              "speechrate" : "http://gpii.net/ns/up/speechRate" } },
   [ "property", "condition", "value" ],
     [ "speechRate", null , 90],
     [ "fontsize", null, "120%" ]
   ]
]
Hope that renders in your email with the indentation I intended.

axelrod:Andy

> Heyho Collin,
>
> Yep, I'm of course open to changes and alterations :) The proposal was
> always meant as a first iteration to give us something to start
> implementation, not as a final result.
>
> I will write my thoughts on profiles down asap :)
>
> Best regards,
> HdM:Andy
>
> -----Original Message-----
> From: Clark, Colin [mailto:cclark at ocadu.ca]
> Sent: Friday, August 03, 2012 11:05 PM
> To: Andreas Stiegler
> Cc: Gottfried Zimmermann (List); <SP1 at cloud4all.info>; <sp2 at cloud4all.info>;
> Accessforall at fluidproject. org; Antranig Basman
> Subject: Re: Conditional preferences
>
> Hi Andy,
>
> On 2012-08-01, at 12:04 PM, Andreas Stiegler wrote:
>> I think it would be helpful to discuss the actual scenarios how and
>> when interaction between the user and the profile takes place and what
>> the job of the different fields (property, condition, value) is in
>> this context. It appears to me that this is an important step to get
>> to a proposal as it defines the requirements and usability parameters
>> that the proposal will have to obey.
>
> Yes, this makes a lot of sense. Let's do it.
>
> I'm wondering if you're also interested in doing some brainstorming on
> variations to this proposal and some alternative approaches? I imagine some
> chatting and sketching might produce some next steps fairly quickly.
>
>> I will prepare a few graphics on a wiki page over the weekend that
>> might serve as a base for discussions. That might be a good step to
>> prepare and discuss in our next full a2a meeting.
>
> Great, I'm looking forward to it. Let me know if I can help at all with the
> work!
>
> Colin
>
> ---
> 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
>



Cheers

andy
-- 
__________________
Andy Heath
http://axelafa.com



More information about the Accessforall mailing list