Hi list,
Here is the point I wanted to raise by the end of the conf-call today.
What we are talking is about completing the SOAP and REST conformance statements, not the data model (which turns to payload in the context of the services).
While I fully agree with the conformance items Mike prepared and what we discussed today, parts of them are about the payload only, not the services to transport them (in particular the Time zone handling).
I could transport the payload via files instead of REST/SOAP, or even by writing on a paper sheet (and giving it to my colleague to set up a meeting). These Time Zone rules would still make sense and remain true - I agree that my paper/pencil-based server implementation would probably be far from compliance because there is no WS-Calendar paper-based Services specification out ;-).
My understanding about the services conformance is that they comprise 3 sets:
- Things related to data preservation over an update round-trip, and for sure common to both Rest and SOAP such as:
o Date and Date-time consistency, including the preservation of their _expression_: dtstart+duration vs duration + dtend vs dtstart + dtend (a real transport issue, but independent from the transport mechanism)
o Some others in Mike’s email
- Things related to services support, and probably common to both Rest and SOAP:
o Are all specified services mandatory to claim conformance ? If not, what is the minimum set ? What about a profile derived from WS-Calendar (is it allowed to subset / extend the set of services) ?
For example, is it mandatory to support the creation service ? The Query service ?
One could imagine an implementation where only the fetchItem is supported (a basic “read-only” server or client).
o Are all services’ parameters mandatory ? If not, what are the default values one shall consider ?
What if I implement the Query service but ignore the propFilter and consider it as an empty thing (or always return my preferred set of props whatever the propFilter value passed with the Query service call) ?
- Things specific to REST and things specific to SOAP:
o Rules for adding services ? In the REST world ? In the SOAP world ?
I am not talking about extending the xCal component/property sets, but adding a specific service
o Rules for adding parameters to the specified services
Is it allowed ? If yes, any rule to be applied to be able to claim conformance ?
As a conclusion:
Interoperability issues from the past are keys for conformance rules in the 1st and 2nd sets.
The 3rd set is probably much simpler, but important for readers and potential implementers of the WS-Calendar specification:
- If everything is optional, and all extensions out of control, then interop can not be reach,
- If everything is mandatory, and all doors for extensions are closed, then interop is easier, but implementation in a particular context is complex and lacking the usually required versatility.
Comments ?
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
