OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-cap message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [emergency-cap] CAP Issue 23 - Specify JSON serialization

There continue to be nasty issues cropping up in the details, especially wrt character encoding. Although not much of an issue for those whose applications just use ASCII, but it's a major pain for the rest of the world's languages. I would be surprised if applications using JSON do not have character encoding problems (indeed, such problems bedevil XML as well). Such problems may not be specific to the serialization itself, but how serialization and structure passing interacts with a programming language, a Web container, an operating system, HTML, and so forth. 

On Tue, Oct 28, 2014 at 10:01 PM, Art Botterell <acb@incident.com> wrote:
Surprised to hear that from you, Eliot.  My intent was quite the opposite, that the question of serializations should be held orthogonal to that of the data structure.  My impression was that you and I had been in agreement on that for many years.

Would you likewise argue that the ASN.1 serialization should be considered somehow lesser than the XML?  Not sure what the ramifications of that might be.  And  of course JSON is already in use in a number of CAP projects, whereas personally I've yet to encounter a real-world ASN.1 CAP implementation.

Particularly now that we're well on the way to a digital signature standard for JSON (see <https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-36>) I think we'd be well advised to be making a visible effort to keep up with the times.  In fact I could see us making something of a PR splash on the theme of how CAP now supports JSON... in line with the OASIS strategy as described at <https://www.oasis-open.org/resources/topics/rest-json>.  Us oldsters might not get it, but the younger generation definitely would.

Indeed, among the younger programmers I've talked with lately XML is described as the COBOL of data serialization... a significant legacy platform that's not going away anytime soon, but not a technology folks are flocking to anymore.

- Art

> On Oct 28, 2014, at 13:28, Eliot Christian <eliot.j.christian@gmail.com> wrote:
> I guess this proposal is for the EM TC to post an informative Committee Note that discusses considerations when JSON is used for processing a CAP alert. The status of such a document would be similar to the OASIS Committee titled "Example Practices: CAP Feeds Version 1.0." (issued 04 March 2014, available at  http://docs.oasis-open.org/emergency-adopt/cap-feeds/v1.0/cn02/cap-feeds-v1.0-cn02.doc ).
> It is important that the EM TC would not reference such a note in the CAP specification. Rather, the specification should remain very clear that a CAP alert message can only be considered "valid" and "compliant" as it is represented in XML format.
> On Tue, Oct 28, 2014 at 1:08 PM, Jacob Westfall <jake@jpw.biz> wrote:
> The CAP SC meeting ran out of time yesterday to discuss Issue 23 regarding JSON.  In the interests of moving the issues along, I'd like to suggest we discuss this issue via the email list/issue tracker and move to quickly resolve it on the Nov 3 call.
> I am supporting the issue.  I've been working with a JSON schema of CAP for some time now with good success.  There are some differences in the schema versus XML and how to implement it, just like with ASN.1.
> I would suggest we follow the path that the OASIS OData standard has taken and produce a separate specification for CAP JSON that merely denotes the differences between the serializations with the XML spec remaining as the primary document.  In addition to OData, I found that other OASIS specs like XDI, XACML, CAL, CMIS, and CAM are all working on JSON serializations as well.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]