Re: JSON Instances

P.S. 

7) Why should the root element for the XML corresponding to the JSON data 
be <json>?  Why not <data>?

8) The second bullet point that contains the encoding instructions for the 
variable "name" should be further decomposed into a second level bullet 
point list.

Thanks,
JB



From:   John Boyer/CanWest/IBM@IBMCA
To:     "Steven Pemberton" <Steven.Pemberton@cwi.nl>
Cc:     "Nick Van den Bleeken" <Nick.Van.den.Bleeken@inventivegroup.com>, 
"Forms WG" <public-forms@w3.org>
Date:   06/02/2011 04:08 PM
Subject:        Re: JSON Instances
Sent by:        public-forms-request@w3.org



Even if the problem were only about numbers and booleans, using a bind 
would make it a lot harder to roundtrip back to json, compared with 
decorating the data itself. 
I also agree that the array case pretty much quashes the idea. 
More generally, it would be preferable if our JSON => XML => back to JSON 
conversion strategy didn't rely on anything outside of XML.  If our 
conversion relied on another XForms construct, like bind, then people 
outside of XForms could not reuse. 

I have several other questions and suggestions related to round-tripping 
the JSON: 

1) Add some way to tell whether the name part of the JSON should have 
quote marks.  Right now it is clear that you need quote marks if the name 
includes non-NMCHAR characters. In this case, you get a name attribute on 
the XML tag.  So maybe a way to always signal use of quote marks is to put 
a name attribute, like this: 

{"size": 50} ==> <json><size name="size" type="number">50</size></json> 
==> {"size": 50} 

The converter becomes really easy too.  Use name attr if given and put the 
attr value in quotes, otherwise use the element name, not in quotes. 

Finally, I think if you take this approach, then there would not be much 
point in debating whether we should use something better than just 
underscores for the illegal chars, right? 


2) I think type="null" is a bit underpowered. I think you really mean 
type="object" because you're just trying to distinguish that the empty 
content means null rather than the string "".   

By the way, I recommend against using xsi:nil because it has to correspond 
to something being nillable="true" in a schema, and it must be manually 
changed to xsi:nil="false" if the element becomes non-empty. 


3) You ask whether the type attr should be replaced with xsi:type.  I'd 
recommend against.  It seems better to separate the issue of converting 
JSON => XML from the  issue of improving the XForms processing of the 
resultant XML. It would always be possible for an XForms author to add an 
XForms bind whose nodeset uses an xpath predicate to select nodes with a 
particular type assignment and then assign a type MIP to those nodes to 
attach a particular schema datatype, e.g. 

<xf:bind nodeset="/descendant::*[type='number']" type="xsd:double"/> 

By the way, it does look like javascript number and xsd:double use the 
same 64-bit IEEE definition, so better to leave this flexible in case the 
form author wants to be more restrictive, e.g. restrict to integer inputs. 


Finally, use of xsi:type would then require us to add the ugly xmlns:xsi 
namespace declaration to the json element. 


4) Attaching starts="array" seems underpowered.  Suppose I have a 
particular node and I need to know whether it is part of an array?  Why 
not attach array="true" to each element from an array?  Or would there be 
any value in setting the attribute array equal to the element name?  Would 
there be a benefit to authors of being able to say 
nodeset="*[array='size']" in order to grab all the nodes in the size array 
separately from array elements that might be at the same hierarchic level? 
 One might think you could achieve the same effect with 
nodeset="size[array='true']", so maybe the boolean is enough. 


5) Is it just a wiki problem that is producing ?? for the translation of 
escaped characters?  If so, I suggest using a hex notation, e.g. \b to 
0x08, \f to 0x0C, \n to 0x0A, \r to 0x0D, and \t to 0x09. 


6) Can you update the wiki to indicate what illegal XML characters you 
might be talking about?  Seems it will be hard to decide what to do about 
the characters without having the research to indicate what they are. 
Maybe there are just a few? 

Thank you, 
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:        "Steven Pemberton" <Steven.Pemberton@cwi.nl> 
To:        "Steven Pemberton" <Steven.Pemberton@cwi.nl>, "Nick Van den 
Bleeken" <Nick.Van.den.Bleeken@inventivegroup.com> 
Cc:        "Forms WG" <public-forms@w3.org> 
Date:        06/01/2011 07:04 AM 
Subject:        Re: JSON Instances 
Sent by:        public-forms-request@w3.org 



The reason they are there is to allow serialization to roundtrip the data. 
 
That might work for numbers and boolean, but I don't see how it would work 
 
for arrays. (But I may be wrong).

Steven


On Wed, 01 Jun 2011 11:10:41 +0200, Nick Van den Bleeken 
<Nick.Van.den.Bleeken@inventivegroup.com> wrote:

> Steven,
>
> Couldn't we use auto generated binds that attach the type information to 
 
> the nodes for that?
>
> Regards,
>
> Nick van den Bleeken
>
>
> On 30 May 2011, at 14:41, "Steven Pemberton" <Steven.Pemberton@cwi.nl> 
> wrote:
>
>> I should note a slight difference with what we had earlier agreed that 
>> dawned on me while firming it up, that got in the way of 
round-tripping.
>>
>> In the transformation of
>>    {"size": 50} and {"size": "50"}
>> you can't tell the difference if you transform both to
>>    <json><size>50</size></json>
>>
>> So I've use the type attribute to (arbitrarily) mark the numeric case:
>>
>>    <json><size type="number">50</size><json>
>>
>> Similarly with the boolean and null cases.
>>
>> Steven
>>
>>
>> On Fri, 27 May 2011 16:51:50 +0200, Steven Pemberton 
>> <Steven.Pemberton@cwi.nl> wrote:
>>
>>> I have rewritten the JSON section, according to my action item.
>>>
>>> http://www.w3.org/MarkUp/Forms/wiki/Json
>>>
>>> Comments gladly received.
>>>
>>> Steven
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>
> ________________________________
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer