It would be good if you can provide some specific examples where JSON is
problematic but XML is easier.
-Subir
*From:*[email protected] [mailto:[email protected]] *On Behalf
Of *Manikkoth Sajeev
*Sent:* Friday, August 24, 2012 11:14 PM
*To:* [email protected]; [email protected]; [email protected]
*Cc:* [email protected]
*Subject:* Re: [paws] XML schema versus JSON, vCard & iCal
Hi,
I would still support XML. JSON libraries are available for all
languages. But interfacing and linking such libraries are problematic on
embedded devices most of the time. And if an implementation vouch for
multiple such non native language libraries then developers life is hell...
/Best Regards,/
/Sajeev Manikkoth/
*From:*"[email protected] <mailto:[email protected]>"
<[email protected] <mailto:[email protected]>>
*To:* [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
*Cc:* [email protected] <mailto:[email protected]>
*Sent:* Saturday, 25 August 2012, 0:38
*Subject:* Re: [paws] XML schema versus JSON, vCard & iCal
WiFi world builds on mandating the implementation (and certification) of
a base spec, and a set of optional features. If an optional feature is
not supported by one of the peers, they can still talk, but not use that
feature. That is basically option B) from Brain’s list.
I’d like to suggest that we recognize that option A) and B) are valid
options, while option C) is invalid, and we should stop debating it.
I’d also like to add the obvious option D) to the list, which is that
both the master devices and DBs support one and the same encoding ;)
Option A) seems to be like a good compromise, and would cut discussions
short, with the only caveat that if there is no strong technical
argument for supporting and specifying two different encodings, then the
iesg may send the document back to the wg to pick one of the two
specified. As Robert mentioned in his email, this has happened in the
past, so it is likely it would happen again. And frankly, I do not see a
strong argument in favor of two different encodings.
Is there anyone who has a technical argument against supporting only one
encoding, being that either xml or json?
Most people speak in favor of JSON, because it is compact and more
efficient. I went through this thread and I saw 2 objections against
picking JSON. One said that JSON requires native Java, which is wrong,
the other objection gave no real reason. So I am wondering if there is
really any valid technical reason against using JSON only?
- Gabor
*From:*[email protected] <mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of *ext Rosen, Brian
*Sent:* Friday, August 24, 2012 10:43 AM
*To:* Benjamin A. Rolfe
*Cc:* [email protected] <mailto:[email protected]>
*Subject:* Re: [paws] XML schema versus JSON, vCard & iCal
Okay:
So, I implement a database, and I implement XML
You implement a device, and you implement JSON
You query my database (let's not get into how you do that query without
deciding XML vs JSON) and discover I implement XML only
What do you do?
Brian
On Aug 24, 2012, at 1:38 PM, "Benjamin A. Rolfe" <[email protected]
<mailto:[email protected]>> wrote:
There are two ways to achieve interoperability when you have an option.
There are many existence proofs of the third way that I mentioned below.
802.11 + WiFi provide many options and a means for devices to share
information about what options each supports, without requiring that any
device implement every option. It works.
That said, I think (A) is the best choice, (B) is not as nice for me,
and (C) is more work than either of the other two.
One is that one end implements both choices and the other end implements
one or both.
The other is that both ends implement one specific choice ("MUST
implement") and both can optionally implement the other choice. Only if
both ends implement the other choice would that be available.
So, in this case we could do one of the following:
A) Databases implement both XML and JSON, devices implement either
B) Both Databases and devices implement one (say XML) and optionally
implement the other (say JSON)
You are advocating for A, Richard was suggesting B.
I don't care, but choice C) Both databases and devices have a choice of
what to implement doesn't work for me (or Richard).
Brian
On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe <[email protected]
<mailto:[email protected]>> wrote:
Apparently I was unclear. I certainly an capable of being wrong as I
practice often, but in this case it is quite unlikely :-).
You do not need to choose only one form to achieve interoperability.
If you have two, let the device implementer figure out which is best for
their particular device requirements and trade-offs. This is
*preferable* from my perspective.
If you provide more than one form in the database, devices using the
database need some means for figuring out which are available. It can't
use it if it doesn't no about it. This is an observations, not an
argument ;-).
It is my *opinion* at the moment that if you provide options, to make
those useful you need to provide a protocol by which devices can
discover what options the database supports. If you have such a
mechanism and all devices use it (a bootstrap protocol), everything
else could be options. This requires additional functions in both
database and device implementations.
If on the other hand the device can "just know" that the database has
two forms available, it won't need to dynamically figure it out. The
device implementer has options and simplicity, so I like it.
Since I am focused on the TVWS devices that need access to the database,
and not a database implementer, shifting burden onto the database
implementer (not me) to reduce the burden on the device implementer (me)
is preferred from my perspective. The database implementer may have
another perspective. Should I point out that there will be a lot more
devices than databases? That might sound like an argument, though, so I
won't....:-j
Ben
Brian is right .. sorry but the rest of you are wrong. J
This is why you have MUST and SHOULD in RFC 2119.
This BTW is a classic argument in IETF terms .. but the argument “let
the market decide” only holds so much validity. You actually have to
choose SOMETHING to create a baseline of interoperability.
A virtually identical argument is now playing out in discussions of
mandatory audio and codec implementations for WEBRTC like things.
IMHO XML MUST anything else defined SHOULD, but MUST on XML and JSON
could work as well. It just leads to a level of complexity in
implementations.
End of argument you now can go back to your regularly schedule
programming. J
*From:*[email protected] <mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of *[email protected]
<mailto:[email protected]>
*Sent:* Thursday, August 23, 2012 5:44 PM
*To:* [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 agree with Brian.
There needs to be a default mandatory to implement option in order to
achieve interoperability.
And this applies to the device and database side of the protocol.
-Raj
*From: *"<ext Rosen>", "[email protected]
<mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
*Date: *Thursday, August 23, 2012 2:43 PM
*To: *Don Joslyn <[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
One of my favorite IETF expressions is "There are no protocol police".
We apply that in lots of ways, but one of them is that if you don't
implement what the document says, you may not get interoperability with
other implementations. On the other hand, the whole point of a protocol
document like ours is that two independent implementations who both
follow the document will interwork. If that wasn't true, why do you
need a standard?
If you say "either" to both ends, then you don't get interoperability.
By your argument, we should stop working, and the product managers will
figure it out using proprietary protocols. The market will decide.
So, I feel strongly that if one end is "either", the other end must be
"both". It's also acceptable to say both ends implement one choice and
the other is optional at both ends. Here, I think it's server does both
and client does either.
It's always possible to build an implementation of a server that only
does one: there are no protocol police.
Brian <as individual>
On Aug 23, 2012, at 3:11 PM, Don Joslyn <[email protected]
<mailto:[email protected]>> wrote:
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]>
[mailto:[email protected] <mailto:[email protected]>]*On Behalf
Of*Benjamin A. Rolfe
*Sent:*Thursday, August 23, 2012 3:05 PM
*To:*[email protected] <mailto:[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:
o Simple-to-use libraries exist for all major languages/platforms
o 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:
o Representation closely matches most data models (nested lists
and maps)
o Simple-to-use libraries exist for all major languages/platforms
o 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
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
ofhttp://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] <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]
https://www.ietf.org/mailman/listinfo/paws
