W3C home > Mailing lists > Public > public-forms@w3.org > November 2010

First write up of JSON

From: Steven Pemberton <Steven.Pemberton@cwi.nl>
Date: Tue, 02 Nov 2010 10:07:55 +0100
To: "Forms WG" <public-forms@w3.org>
Message-ID: <op.vljczhbgsmjzpq@steven-750g>
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


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":  

gets transformed to


	{"company":"example.com", "locations":[{"place": "Amsterdam"}]

would appear as


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

	   <locations type="array"><place>Amsterdam</place></locations>

There is no chance of name clashes, since there are no attributes in JSON.

Received on Tuesday, 2 November 2010 09:08:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:04 UTC