The hidden TC member is going to full disclosure ;-)
As Toby wrote, I wanted to make sure I did not miss a piece of document somewhere (that would have contained the information I was seeking) before exposing my concerns to the list.
While I am fully happy with what we defined in the WS-Calendar specifications, I am not sure we have been fully right in term of helping people implementing WS-Calendar straightforward.
In the last weeks I took the seat of an implementer of the SOAP services, and put myself in the position of a non-member of this group (trying to forget the discussions and working documents I had).
All of the elements required to implement the SOAP services appear and are described in the WS-Calendar SOAP specification: Methods, Parameters and their data types
And the payload is described in the main spec. Everyone can get full understanding of WS-Calendar and the SOAP services by reading them.
But the package does not contain the main input an implementer will wait for: The machine-readable description of the methods and parameters as usually supplied under the form of a Wsdl file, or xsd file.
The question is: Should we add these to the WS-Calendar package?
Adding them to the package or referencing them (as published by CalConnect) would not change anything to the semantic of the data and services; would not change the payload.
It would simply help developers going the easy way, taking the machine-readable description as the main input, and avoiding mistakes while reconstructing the Wsdl:
- Namespace and service references,
- Parameters’ names and types,
- Error typing
- …
All of those are described in the paper document, but not in a file you can give directly as input to your preferred dev tool.
As a conclusion:
Such a modification in the WS-Calendar package/references would not change a single bit on the wire between a SOAP client and a SOAP server, it would just enable people to implement it faster and in a more error-prone manner, thus improving interoperability.
I would personally be happy to see our spec quality improved by adding this reference. Does it change something ? No, it will just help people doing things right at first shot.
All comments are welcome.
Regards
Benoît LEPEUPLE
Product Manager
ARC Informatique
2 avenue de la cristallerie - 92310 SEVRES - FRANCE
Tel: +33 1 41 14 36 00 - Mobile: +33 6 87 80 20 43
Email : b.lepeuple@arcinfo.com
From: ws-calendar@lists.oasis-open.org [mailto:ws-calendar@lists.oasis-open.org] On Behalf Of Toby Considine
Sent: Friday, August 03, 2012 4:22 PM
To: ws-calendar@lists.oasis-open.org
Subject: [ws-calendar] SOAP Specification
Some significant concerns have been raised by a TC member about interoperability using the current working draft specification that have caused me to not submit the SOAP document for release as a Committee Specification at this time. In particular, it was suggested that without WSDL and a normative XSD, we will fail to achieve interoperabilty using this specification.
The TC member has not submitted his comments to the TC yet, and they are not mine to share. I believe part of the reason is that he is awaiting consensus from others doing interoperability testing.
With these concerns unaddressed, the current draft loses my vote for release as a committee specification. As the changes to the text are minimal, it seems a waste of effort to go through a public review process. I have only one vote. If there any on the TC who would like to proceed on the path of Committee Specification release, please contact me (preferably to the list) and I will request the initiation of the vote.
tc
"You can cut all the flowers but you cannot keep spring from coming."
-Pablo Neruda.
Toby Considine TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee | | Email: Toby.Considine@gmail.com |