Following on our productive JSON discussion yesterday
(http://www.w3.org/2010/11/01-forms-minutes.html#item03) I have written it
up on the wiki page
http://www.w3.org/MarkUp/Forms/wiki/index.php?title=Json&action=submit
However, in writing it up, I came to some slightly different conclusions.
The main discussions was on how to deal with empty and single-element
arrays. Since an array like
{"company":"example.com", "locations":[{"place": "Amsterdam"},{"place":
"London"}]
gets transformed to
<json><company>example.com</company>
<locations><place>Amsterdam</place>
<place>London</place>
</locations>
</json>
then
{"company":"example.com", "locations":[{"place": "Amsterdam"}]
would appear as
<json><company>example.com</company>
<locations><place>Amsterdam</place></locations>
</json>
which would be indistinguishable from
{"company":"example.com", "locations":{"place": "Amsterdam"}}
So, in order to be able to re-serialise correctly, the system needs to be
able to distinguish the two cases. The conclusion we came to in the
meeting was to use new sorts of MIP, usually used internally to the
system, so that the system knows that an element actually represents an
array. But then when the instance doesn't originate from externally, but
is created from within the form, you need a way to set the MIP:
<bind ref="locations" json-array="true()"/>
which means new XForms facilities.
While writing it up, I realised that the alternative solution of using
attributes would not require new XForms facilities. The knowledge is then
exclusively in the parse and synchronise parts. So now the above array
gets read as
<json><company>example.com</company>
<locations type="array"><place>Amsterdam</place></locations>
</json>
There is no chance of name clashes, since there are no attributes in JSON.
Steven