[Accessforall] Conditional preferences

Clark, Colin cclark at ocadu.ca
Sun Aug 5 21:54:36 UTC 2012

Hi Andy Heath and Antranig,

On 2012-08-05, at 4:25 PM, Antranig Basman wrote:
>> 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.
> Thanks for these suggestions - although we will indeed frequently need to map between XML and JSON representations of the same data, in general I am against the importation of "XML-isms" such as the term "xmlns" into the JSON dialect. The whole purpose of having inter-format mapping is to ensure that each participant can "speak like a native". To this aim, each format will need to eschew, or have "designed out of it" an essential dependency on names or structures which are only intelligible in a different format - at least where such formats are designed by us! Clearly where such structures already exist it is part of our mission to adapt to them.

I agree with Antranig about avoiding the migration of XMLisms into our JSON dialect. Thankfully, they're two very different representations, and we should probably try to optimize each AfA binding to its format as idiomatically as possible.

As for your "difficult to read" point, did you look at the "Alternative, Global Style" suggestion at the bottom of the wiki page? It looks very close to your example, and I think is quite simple to read. What do you think of it?


Colin Clark
Lead Software Architect,
Inclusive Design Research Centre, OCAD University

More information about the Accessforall mailing list