W3C home > Mailing lists > Public > public-forms@w3.org > December 2011

Re: JSON/mediatypes/src/replace

From: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
Date: Fri, 2 Dec 2011 20:03:21 +0000
To: John Boyer <boyerj@ca.ibm.com>
CC: Steven Pemberton <Steven.Pemberton@cwi.nl>, "<public-forms@w3.org>" <public-forms@w3.org>
Message-ID: <0B394C55-CBC5-4285-A84B-608F557A1968@inventivegroup.com>
Hi John,

You probably won't believe it, but I was making exactly the same points yesterday. Also in a lot of cases your instance that is used to create the request isn't the instance that receives the data. So you are forced to specify the serialization method in those cases.

Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office fax: +32 3 821 01 71


On 02 Dec 2011, at 18:35, John Boyer wrote:

Hi Steven,

It might be better to go with this alternative of saying that the output is XML unless otherwise stated.

One issue that arises with the automatic serialization is what to do if an instance is read as XML (or JSON) and then a replacement submission replaces *part* of the instance with JSON (or XML).  There's no general rule about the submission replacement format affecting the subsequent serialization of the instance.

Some specialized version of that rule doesn't seem to help much either, i.e. it makes more friendly a thing which was not all that unfriendly anyway.  The application author will know whether the service being contacted expects to receive json or xml, so it does not appear to be a problem that the author would request json serialization in the mediatype.

John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: boyerj@ca.ibm.com<mailto: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<mailto:Steven.Pemberton@cwi.nl>>
To:        public-forms@w3.org<mailto:public-forms@w3.org>
Date:        02/12/2011 08:29 AM
Subject:        Re: JSON/mediatypes/src/replace

Of course, the other option is always to serialize as XML unless otherwise


On Fri, 02 Dec 2011 16:08:36 +0100, Steven Pemberton
<Steven.Pemberton@cwi.nl<mailto:Steven.Pemberton@cwi.nl>> wrote:

> Take this XForm (fragment), which loads an instance, changes a value,
> and writes it out again:
> <model>
>                  <instance src="http://example.com/data"/>
>                  <submission id="put" resource="http://example.com/data" method="put"/>
>                  <action ev:event="xforms-ready">
>                                   <setvalue ref="date" value="now()"/>
>                                   <send submission="put"/>
>                  </action>
> </model>
> I believe we agreed (just checking) that this will work whether the data
> coming in is XML or JSON. In other words, the submission uses the same
> mediatype to serialise as the instance was populated with.
> I think the same should be true in this case, where instead of using
> src=, the instance is populated with a submission replace="instance."
> Again, just checking.
> <model>
>                  <instance id="i"/>
>                  <submission id="get" resource="http://example.com/data" method="get"
> replace="instance" instance="i"/>
>                  <submission id="put" resource="http://example.com/data" method="put"/>
>                  <action ev:event="xforms-ready">
>                                   <send submission="get"/>
>                                   <setvalue ref="date" value="now()"/>
>                                   <send submission="put"/>
>                  </action>
> </model>
> Steven

This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.


Inventive Designers' Email Disclaimer:

(image/png attachment: image001.png)

(image/png attachment: image002.png)

(image/png attachment: image003.png)

Received on Friday, 2 December 2011 20:03:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:48 UTC