I both object and concur with the proposal. First, my objections.
XML and SOAP are not going to disappear. That is like saying FORTRAN is going to disappear. Just the other day I had a conversation on this very topic with a representative from NGA geospatial IT and standards community. I questioned the requirements for an upcoming OGC testbed activity focused on SOAP and web services community. (http://www.opengeospatial.org/standards/requests/139 section 8.3). I was quickly educated to the fact that the DoD/Intel community has a huge investment in SOAP based web services and will continue to into the future. I know the same is true for DHS. Think NIEM. I also recently attended an Electric and Gas Utility CIO Cybersecurity conference. SOAP based enterprise web services. Basicly, many large enterprises have a significant investment in SOAP based deployments.
At the same time, all of these organizations are also implementing REST APIs and using JSON encodings. Quite often they are looking at defining best practices and principals for SOAP/SOA solutions and REST/ROA solutions. Essentially, providing developers, vendors, and procurement guidance as to which approach to use for given use cases. The decision is not binary. Quite often, enterprises such as the Ordnance Survey (UK) have moved to a blended approach. User the right tool for the job at hand.
One last point as an example of why a decision to forget SOAP based services and move to REST/JSON only is inappropriate and short sighted. Just this morning I received an email from an individual who is performing rigorous performance and other testing of JSON based encodings versus XML. A summary of his initial findings:
1) The big attraction to JSON is that it is simpler than XML.
2) JSON encodings of complex content are no simpler than XML encodings (try it yourself. The JSON and XML should be semantically equivalent).
3) Therefore, we should view JSON not as an XML replacement, but as a light-weight alternative.
Speaking as a member (and past CTO) of the OGC, I can categoricaly state that the OGC is now supporting both approaches in OGC standards work. Why? Because that is what the community is demanding. The OGC community has now also defined how to use JSON encodings with the existing OGC Web Services standards baseline.
Submitter Proposed Solution
Keep the existing endorsed Web Services approach and define a complementary REST/JSON API.