[Accessforall] Conditional preferences

Antranig Basman antranig.basman at colorado.edu
Sun Aug 5 20:25:15 UTC 2012

On 05/08/2012 04:02, Andy Heath wrote:
> 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.

We would indeed adopt an unambiguous representation as you say, such that the array structure is used even 
if it only contains one value. In general we want to make it as easy as possible to supply a schema for our 
payloads, for example using the JSON schema technology, and any kind of "variant types" at a location in the 
schema would make this much more complex.

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

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.

Please see my other suggestion (close to the end of the document) in which "condition" and "value" are 
knocked together into a single entry, which now needs no name - this eliminates the need for the cumbersome 
"null" entry and the extra level of arrays in your final example.


More information about the Accessforall mailing list