Hi all,
I am not sure whether there is something in JSON to define the value
type or the range of value, because in XML
the type and the value range of every element can be defined exactly. Is it
necessary to deal this in XML/JSON ?
--Xinpeng Wei
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Friday, August 17, 2012 7:26 AM
To: [email protected]; [email protected]; [email protected]
Cc: [email protected]
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]] On Behalf Of ext
Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: '[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]]
Sent: Monday, August 13, 2012 06:04 PM Eastern Standard Time
To: Peter Stanforth
Cc: Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [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]>
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]> 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]]
>Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time
>To: Teco Boot; Benjamin A.Rolfe
>Cc: [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]>
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]
>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>
>>>
>>> _______________________________________________
>>> paws mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/paws
>>
>>_______________________________________________
>>paws mailing list
>>[email protected]
>>https://www.ietf.org/mailman/listinfo/paws
>
>_______________________________________________
>paws mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
--
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
