Hi Ben, That was my original suggestion, and I still think it makes the most sense. Thanks for supporting the proposal. Don
From: [email protected] [mailto:[email protected]] On Behalf Of Benjamin A. Rolfe Sent: Thursday, August 23, 2012 3:05 PM To: [email protected] Subject: Re: [paws] XML schema versus JSON, vCard & iCal Someone suggested that PAWS define both, and let the vendors decide which ones to implement. That makes the most sense for both DB and device vendors. Markets will probably drive DB vendors to do both. Device vendors will do what fits the market segment they're after. Why over-constrain (or argue when natural selection will take care of it for us?). B Sounds good to me. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Tuesday, August 21, 2012 12:42 AM To: [email protected]<mailto:[email protected]> Subject: Re: [paws] XML schema versus JSON, vCard & iCal Now I can't see anymore any willingness to agree on one or the other encoding. To prevent endless discussions on this topic I'd suggest we move forward with supporting both in the DB and either one in the master device. Any objections? Gabor From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of ext Das, Subir Sent: Monday, August 20, 2012 2:50 PM To: Don Joslyn; Vincent Chen; Weixinpeng Cc: [email protected]<mailto:[email protected]>; Manikkoth Sajeev Subject: Re: [paws] XML schema versus JSON, vCard & iCal We have a half a dozen or more TVDB radio vendors that use/prefer JSON and we will vote for JSON if we had to pick one. Also I will copy the following two important points: * Simple-to-use libraries exist for all major languages/platforms * Don't need a tool chain to work with the data, as is typically needed for XML From: [email protected]<mailto:[email protected]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Don Joslyn Sent: Monday, August 20, 2012 4:54 PM To: Vincent Chen; Weixinpeng Cc: [email protected]<mailto:[email protected]>; Manikkoth Sajeev Subject: Re: [paws] XML schema versus JSON, vCard & iCal Please see my comments below... Thanks, Don From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Vincent Chen Sent: Monday, August 20, 2012 2:56 PM To: Weixinpeng Cc: [email protected]<mailto:[email protected]>; Manikkoth Sajeev Subject: Re: [paws] XML schema versus JSON, vCard & iCal * One of our goals is to strive to lower the cost and complexity for device manufacturers. This lowers the barrier for building a robust ecosystem. [DJ - The "cost" and complexity of using XML has not been an issue for the half dozen TVBD vendors that have already used XML. Maybe we need to better define "cost"?] * To reduce complexity and cost for device makers, supporting 1 encoding is better than both, as Brian points out. WiFi access points that "just work" anywhere in the world serves as a good model. [DJ - I proposed that the databases support both XML and JSON, devices only need to support one to talk to the database. Our current database supports XML and JSON, but if I'm forced to pick only one, then I will vote for XML because it's the one that we currently use on all embedded devices.] * There's a trend for APIs on the web towards JSON (Twitter, FourSquare, Facebook, Google, etc.). One of the major reasons is that developers (client-side) prefer it for its simplicity: * Representation closely matches most data models (nested lists and maps) * Simple-to-use libraries exist for all major languages/platforms * Don't need a tool chain to work with the data, as is typically needed for XML. Apparently, the efficiency gains of JSON also matter to the scalability of serving systems. [DJ - I can't argue against these listed pros for JSON, especially when you're dealing with a lot of data (like Twitter, FourSquare, Facebook and Google does). But I'm assuming that PAWS messages will not be exchanged nearly as often as the applications mentioned above. But again, I know JSON is more efficient, can't argue with that.] * At the end of the day, it's the data model that matters, rather than the encoding. We (Google) are actually neutral on XML vs JSON, as long as we're clear on what device makers want. It would be good to get feedback from device makers (especially of embedded devices) regarding experiences supporting XML vs JSON. Don, can you elaborate on the types of devices that already support XML? [DJ - We currently support half a dozen TVDB radio vendors (embedded devices) using XML, non using JSON. XML has not been a burden, and the amount of data that needs to be exchanged between device and database is not that much or exchanged that often.] On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <[email protected]<mailto:[email protected]>> wrote: Considering of the design of database discovery protocol, the LoST protocol may be used and LoST is based on XML, so I think XML may be preferred. --Xinpeng Wei From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:26 PM To: Manikkoth Sajeev; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Re: [paws] XML schema versus JSON, vCard & iCal I don't really care whether we use json or xml as a matter of protocol design or implementation, but I am a big fan of reusing standards rather than defining new ones, and I would not want to see the choice of json mean we then decide to roll our own versus using existing standards based on the idea there is no json representation of an existing standard. So, if choosing json means folks feel free to ignore existing xml based standards such as xCard and LoST, then I would not want to use json. I would prefer to not have "both", because of interoperability complications. If there is rough consensus for both, then I would assert that all servers have to implement both and the client can implement either. There are json validators, so I don't think that is a big deal. My experience in protocol design on the Internet is that decisions made solely or even largely because of compactness advantages rarely are good choices. If you like json because it is smaller, then I believe you need a much better reason. Binary doesn't work for me, at all. I have been involved in big binary vs text wars in protocol design. Text wins, binary loses, in my opinion. Brian <as individual> From: Manikkoth Sajeev <[email protected]<mailto:[email protected]>> Reply-To: Manikkoth Sajeev <[email protected]<mailto:[email protected]>> Date: Thu, 16 Aug 2012 22:37:38 -0400 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "Rosen, Brian" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [paws] XML schema versus JSON, vCard & iCal Hi, Can it not be both JSON and XML supported? I would vote for that. Future implementations may prefer XML as it is generic, omni present, easy to understand and validate. For compactness may be a binary xml option can also work. JSON I think will necessitate implementation to be native Java and may not be as friendly with other implementation languages. Best Regards, Sajeev Manikkoth Mobile: +918792292002<tel:%2B918792292002> Email: [email protected]<mailto:[email protected]> http://www.linkedin.com/in/mksajeev From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Sent: Friday, 17 August 2012, 4:55 Subject: Re: [paws] XML schema versus JSON, vCard & iCal We have not heard any objections for using JSON encoding instead of XML. Therefore, let's go for JSON, and close this thread. - Gabor -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of ext Rosen, Brian Sent: Monday, August 13, 2012 3:14 PM To: 'Vincent Chen'; 'Peter Stanforth' Cc: '[email protected]<mailto:[email protected]>' Subject: Re: [paws] XML schema versus JSON, vCard & iCal json is okay with me. I'd prefer an ISO time stamp rather than a time in seconds since epoch. It's very easy to parse, and its simpler to use and debug. Don't care a whole lot about that Brian <as individual> -----Original Message----- From: Vincent Chen [mailto:[email protected]<mailto:[email protected]>] Sent: Monday, August 13, 2012 06:04 PM Eastern Standard Time To: Peter Stanforth Cc: Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email protected]<mailto:[email protected]> Subject: Re: [paws] XML schema versus JSON, vCard & iCal XML vs JSON Between XML and JSON, JSON messages are more compact and easier to process (parsing, synthesis). As clarification, JSON does not require JavaScript or a Browser. It is a text-based representation of data that is language independent, yet well-matched to all major languages. JSON-handling libraries exist for numerous languages (see of http://json.org/) and seem to be reasonably light weight. Timestamps As for timestamp specifications, should we consider just using seconds since the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for datetime-string parsing on devices, assuming devices already have native libraries that provide time in this format. Is that a valid assumption? Of course, this is less human-readable.... On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth <[email protected]<mailto:[email protected]>> wrote: Whenever we built mobile devices we never dealt with IETF, in our sensor days even an IP stack was a challenge,so I would defer to the device guys on that one. On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" <[email protected]<mailto:[email protected]>> wrote: >Our experience in the IETF over many years is that economizing message >size and compromising utility and security in search of efficiency of >implementation on small devices is a poor trade off. I am not advocating >being wasteful of resources, but I don't think we should seriously >consider the overhead of XML or json to be significant. > >Assuming a json library can be loaded on a small device is reasonable. > >Brian (as individual) > > > > -----Original Message----- >From: Peter Stanforth [mailto:[email protected]<mailto:[email protected]>] >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time >To: Teco Boot; Benjamin A.Rolfe >Cc: [email protected]<mailto:[email protected]> >Subject: Re: [paws] XML schema versus JSON, vCard & iCal > >Not all masters run over the core network. >Some of the Use cases have a master talking to another OTA >We should not assume that all Masters are attached to utility power so we >should be sympathetic to processing energy use also. > >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <[email protected]<mailto:[email protected]>> wrote: > >> >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het volgende >>geschreven: >> >>> Compactness of messages is important, but it is also important (to me >>>at least) to be realizable in an implementation with limited resources, >>>such as embedded devices in what are now popularly called "M2M" >>>applications. A lot of these devices could use IP all the end to end, >>>but may have a very compact, simple stack and applications (i.e. no >>>browser). Is JSON typically implemented when there is no browser? >>>Would it be hard to do in a resource constrained device (i.e. where we >>>talk about memory size in Kilo-bytes still). >> >>In use cases and requirements document, there are no requirements for >>protocol performance. I guess OS/IP/TCP/TLS code size supersedes needs >>for JSON or XML. >> >>Same for timing: TCP/TLS connection setup will take more than the PAWS >>message exchange, I think. This may be of importance when using satcom >>links. >> >>Because PAWS runs between master and database, over core network, >>performance is not our primary concern. But as always, it is good to keep >>an eye on efficiency. >> >>Teco >> >>> Thanks >>> Ben >>> >>> >>>> We had a discussion on XML vs. JSON. I prefer the one with most >>>>compact messages. >>>> >>>> On vCard and JSON: what is the status of "A JavaScript Object Notation >>>>(JSON) Representation for vCard"? >>>> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00 >>>> >>>> On valid times: can we use same format as certificates? They have >>>>similar simple requirements: valid notBefore& notAfter. >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5 >>>> >>>> Teco >>>> _______________________________________________ >>>> paws mailing list >>>> [email protected]<mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> _______________________________________________ >>> paws mailing list >>> [email protected]<mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>[email protected]<mailto:[email protected]> >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >[email protected]<mailto:[email protected]> >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
