- From: <paul.downey@bt.com>
- Date: Thu, 7 Jul 2005 21:25:35 +0100
- To: <umit.yalcinalp@sap.com>, <peter.hendry@capeclear.com>, <www-ws-desc@w3.org>
Umit >As a vendor that considers web services interoperability a major > requirement and would like to see versioning problem to be solved > interoperably, we have concerns as to positioning the mustIgnores to be > the norm as the strong preference of the wg. In our opinion, this is one > dimension of versioning and there is no guarantee that the data binding > tools may interoperate since their choices are proprietary. Therefore, > we share the concerns that Arthur has been bringing up. Interoperability has been our number one concern. Let's face it, interoperability is essentially the only reason we use Web services! But, we also have enough experience from deploying long lived services used by a number of different customers to be aware of the cost of having to manage multiple copies of the same service cloned for just the smallest of changes. That's the status quo with Web services today, and one which comes as a surprise to many who assume that the reward for using XML, a self describing format, is the ability to add additional increments of optional values without breaking existing interactions. I'm unclear how the principle of which values should be ignored is likely not to be interoperable, given the approach is fairly simplistic and we have the PSVI technique as a reference implementation. [snip] > WSDL 2.0 has come a long way. If we want adoption and implementations to > be emerging rapidly, incorporating an extended semantics of XML Schema > will make vendors to adopt WSDL 2.0 later, not sooner. This is raising a > bar which is not really appropriate as the default behavior. That's a fair point, however as discussed, it's possible to easily layer existing schema processors to strip out psvi:notKnown values when validating; binding and mapping tools able to jump over unexpected attributes and elements with little, or in some cases no change. I'd anticipate CR testing to expose issues with implementations. Paul
Received on Thursday, 7 July 2005 20:25:41 UTC