EM CAP SC

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.

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." (issue d   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.

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. >

Perhaps I am raising a discussion here that has already happened but I am concerned. If I build a system that is 100% compatible with the new JSON encoding - am I CAP 1.2 compliant? Is there some obligation on the receiving end to accept both JSON and the widespread XML format? I maintain a system (that Jake built incidentally) that is 100% CAP (and CAP-CP) compatible. Am I now on the hook to plan for incoming JSON? cheers, Darrell 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. > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

You're right, Darrell... we crossed this Rubicon several years ago when we adopted the ASN.1 encoding alternative. As a result, under the strictest possible interpretation your system isn't really "100%" unless it supports ASN.1 as well as XML. However, compliance is ultimately what we say it is... there's a section in the spec for just that topic. We might want to consider defining both a "compatible" level and a "fully" or "globally compatible" level. (We might also want to consider partnering with an open-source effort to create a freely-usable library to facilitate conversion among the XML, ASN.1, JSON formats and whatever other encodings may arise for CAP in the future.) And of course it's important to distinguish between standard-compliance and system interoperability. Unfortunately the former doesn't guarantee the latter, what with different local profiles and network transport arrangements overlaying the fundamental message format. One might say that standard compliance is necessary but not sufficient... an essential first step, but not an occasion for declaring the interoperability problem solved! The good news is that implementing JSON support is generally much simpler, technically, than parsing and marshaling XML (or ASN.1). - Art > On Oct 29, 2014, at 02:44, Darrell O'Donnell <darrell.odonnell@continuumloop.com> wrote: > > Perhaps I am raising a discussion here that has already happened but I am concerned. > > If I build a system that is 100% compatible with the new JSON encoding - am I CAP 1.2 compliant? Is there some obligation on the receiving end to accept both JSON and the widespread XML format? I maintain a system (that Jake built incidentally) that is 100% CAP (and CAP-CP) compatible. Am I now on the hook to plan for incoming JSON? > > cheers, > > Darrell >

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. >

If anything the character-encoding situation is a bit simpler in JSON... most things are. However, there are validated solutions for XML internationalization as well... the problem being that many (probably most) implementers aren't fully abreast of them. "I18N" is still viewed in many English-speaking software shops as an arcane specialty. Programmers in other parts of the world tend, in my experience, to be a bit more cognizant. You do raise an interesting additional question, however, which is whether it might be beneficial to specify the character encoding, optionally like the language, in the CAP message body itself. How does ASN.1 address that, I wonder? - Art > On Oct 29, 2014, at 07:20, Eliot Christian <eliot.j.christian@gmail.com> wrote: > > 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. >

Hi, Thanks to everyone who has weighed in so far regarding issue 23 - JSON. If there are others with comments, please make sure you submit them before the meeting on Monday. My own two cents on the discussion so far. Regarding the concerns about serializations of CAP other than XML being valid. ASN.1 is an entirely valid method for exchanging CAP messages, and has been for years. It just so happens that its uptake has been extremely low, and there have been no impacts on implementers because of this, but it still doesn't negate the fact that CAP messages come in two flavours. So if the justification that XML must be the only way to exchange CAP messages is used to reject issue 23, then I would certainly move that we must apply the same logic and remove ASN.1 as well. If issue 23 is accepted, I do not believe that CAP JSON is thereby fait accompli. The OASIS process would still have to be followed with committee drafts, comment periods, rounds of voting, etc. If during the drafting process any showstoppers with JSON arise, or there is overwhelming negative comments from the CAP community, then CAP JSON would not move forward. I support the issue because JSON has overtaken XML, for good or bad, and believe the effort should be made to seriously consider its use. A draft spec would address some of the important concerns that have been raised such as encoding, transformation, digital signatures, etc and without which, a well informed decision really can't be made. If it ends up being rejected, it would at least provide those of us who get regular questions about CAP and JSON, the ability to point to some valid reasons why JSON isn't available, rather than the shrugs and contradictions we have to offer now.

I think that including JSON makes a good signal to the marketplace that we're onboard with the directions being taken, even with our continued support of xml. Rex On 10/31/2014 12:09 PM, Jacob Westfall wrote: Hi, Thanks to everyone who has weighed in so far regarding issue 23 - JSON. If there are others with comments, please make sure you submit them before the meeting on Monday. My own two cents on the discussion so far. Regarding the concerns about serializations of CAP other than XML being valid. ASN.1 is an entirely valid method for exchanging CAP messages, and has been for years. It just so happens that its uptake has been extremely low, and there have been no impacts on implementers because of this, but it still doesn't negate the fact that CAP messages come in two flavours. So if the justification that XML must be the only way to exchange CAP messages is used to reject issue 23, then I would certainly move that we must apply the same logic and remove ASN.1 as well. If issue 23 is accepted, I do not believe that CAP JSON is thereby fait accompli. The OASIS process would still have to be followed with committee drafts, comment periods, rounds of voting, etc. If during the drafting process any showstoppers with JSON arise, or there is overwhelming negative comments from the CAP community, then CAP JSON would not move forward. I support the issue because JSON has overtaken XML, for good or bad, and believe the effort should be made to seriously consider its use. A draft spec would address some of the important concerns that have been raised such as encoding, transformation, digital signatures, etc and without which, a well informed decision really can't be made. If it ends up being rejected, it would at least provide those of us who get regular questions about CAP and JSON, the ability to point to some valid reasons why JSON isn't available, rather than the shrugs and contradictions we have to offer now. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Rex Brooks Starbourne Communications Design Email: rexb@starbourne.com GeoAddress: 1361 Addison St. Apt. A Berkeley, CA 94702 Phone: 510-898-0670 --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

JSON is quite early in its life and I agree with Jacob that an informed decision cannot be made until many issues are researched and clarified, i.e. encoding, transformation, digital signatures, etc. Elysa
Original Message----- From: emergency-cap@lists.oasis-open.org [ mailto:emergency-cap@lists.oasis-open.org ] On Behalf Of rexbroo Sent: Friday, October 31, 2014 9:27 PM To: emergency-cap@lists.oasis-open.org Subject: Re: [emergency-cap] CAP Issue 23 - Specify JSON serialization I think that including JSON makes a good signal to the marketplace that we're onboard with the directions being taken, even with our continued support of xml. Rex On 10/31/2014 12:09 PM, Jacob Westfall wrote: > Hi, > Thanks to everyone who has weighed in so far regarding issue 23 - JSON. If there are others with comments, please make sure you submit them before the meeting on Monday. > > My own two cents on the discussion so far. Regarding the concerns about serializations of CAP other than XML being valid. ASN.1 is an entirely valid method for exchanging CAP messages, and has been for years. It just so happens that its uptake has been extremely low, and there have been no impacts on implementers because of this, but it still doesn't negate the fact that CAP messages come in two flavours. So if the justification that XML must be the only way to exchange CAP messages is used to reject issue 23, then I would certainly move that we must apply the same logic and remove ASN.1 as well. > > If issue 23 is accepted, I do not believe that CAP JSON is thereby fait accompli. The OASIS process would still have to be followed with committee drafts, comment periods, rounds of voting, etc. If during the drafting process any showstoppers with JSON arise, or there is overwhelming negative comments from the CAP community, then CAP JSON would not move forward. I support the issue because JSON has overtaken XML, for good or bad, and believe the effort should be made to seriously consider its use. A draft spec would address some of the important concerns that have been raised such as encoding, transformation, digital signatures, etc and without which, a well informed decision really can't be made. If it ends up being rejected, it would at least provide those of us who get regular questions about CAP and JSON, the ability to point to some valid reasons why JSON isn't available, rather than the shrugs and contradictions we have to offer now. > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > -- Rex Brooks Starbourne Communications Design Email: rexb@starbourne.com GeoAddress: 1361 Addison St. Apt. A Berkeley, CA 94702 Phone: 510-898-0670 --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php