- From: Steven Pemberton <Steven.Pemberton@cwi.nl>
- Date: Tue, 02 Nov 2010 10:07:55 +0100
- To: "Forms WG" <public-forms@w3.org>
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
Received on Tuesday, 2 November 2010 09:08:42 UTC