[Accessforall] Conditional preferences

Andy Heath andyheath at axelrod.plus.com
Mon Aug 6 11:56:30 UTC 2012


Hi both (et. al.)

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

I disagree - give me a technical reason why. We are, after all going
to have to have bits of json and bits of xml interoperating (legacy
is here for a time - and it may be that xml is better suited to 
embedding in documents - certainly until some of the same mechanisms
are evolved for json.  Note my comment below the next para.

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

I see your point. What you call "bindings" is analogous to what I called 
"xmlns" (but doesn't hit the "cultural" issue amongst programmers
because its "disguised" ;-) ).

There are two *serious* points here though - 1) you see to really use
json in earnest for serious exchange and in the absence of tools,
you guys seem to me to be experiencing a need to develop similar 
mechanisms as were developed in xml (namespaces aren't *only* about 
distributed spaces), and 2) Using URL's won't matter when we have
decent tools because we won't see them - what's the first thing I
would do if implementing a useful tool in this area - I'd implement
*exactly* the mechanism we are talking about in order to hide URL's.
Of course I might keep them in ram not in a representation in 
longer-persistent memory.  But on the xml-json front, I think we need to
bridge these technologies and don't see a reason to do it in a non-open 
way - if we are in the game of playing only with existing approaches 
then we might as well all use wcag and go on holiday.  There are
real reasons to bridge the technologies.

With respect to the example, I think both yours and mine are wrong 
Colin. Certainly in my example I was ignoring that "condition" can also
occur multiple times with the same "property".  That trick of having
an array for the attribute value whenever the key occurs more than once
only works with what I might call "dictionaries" - entities with
two parts - name/key and value - it doesn't work when we have
more than two as we do here and its tricky to get a structure that
is so neat that does. Your example has "condition" missing. Mine
glosses over it because the "condition"'s are all "". Condition also
should be an array, but then there is more than one way to do the value
field (analogous to breadth-first or depth-first trees) - perhaps best 
packed as objects inside an array for condition ?

["pref1" : ["condition1" : ["value1", "value2" ] ] }

?
andy

>
> http://wiki.gpii.net/index.php/Simplifying_Preferences_Documents#Bindings_for_Long_URL_Names.2C_Simplified_Conditional_Evaluation




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



Cheers

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



More information about the Accessforall mailing list