Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Non-schema approach to web service design: comments?
 Michael Champion wrote: > On 10/28/05, bryan rasmussen <rasmussen.bryan@g...> wrote: > >>On 10/28/05, Tech Rams <techmailing@y...> wrote: >> >>>What is in the contract that you are not able to express in WSDL/XSD? >> >>You can't be serious, the limitations of XML Schema are so maddening ... > > I'm not sure that's the question. The one I'd like to see answered is > "what is in a REAL WORLD contract that you can't express in XSD, BUT > COULD BE EXPRESSED IN SOME OTHER DECLARATIVE SCHEMA LANGUAGE." Co-occurrence constraints seem straightforward for a schema language: they just didn't get into XML schema, for reasons long discussed here... Our experience, however, tells us that co-constraints are important for web service definitions. Functional constraints (e.g. this value must satisfy a checksum, etc.) can't be done in any schema language. But this might be resolved through some sort of extension mechanism for custom, externally-defined types. That's what our own language does: we use XSD simple types, but extend this with custom types for checksums, etc. > Don't get me wrong ...The fact that W3C put out a schema language that > took the work 5 years to even begin to understand and implement > consistently *is* maddening. I'm no longer convinced that it is > standing in the way of getting real work done, however. In this context I am saying (I hope consistently) two things: 1) Our service architecture need checksums / simple 'functional' variable constraints. This gap is a problem for us, and likely for others. 2) Ditto for co-constraints Our developers / designers want to declaratively define interface contracts so that they encompass as much of the actual business contract as possible. In this context, the lack of (1) and (2) is a real problem, and gets in the way of our work. For (2) the team admits - for some cases - to XML Schema workarounds. But that would mean taking a very simple business rule and kludging it into a complex, counterintuitive XML Schema construct that largely obscures the real reason behind the constraint. They are, to put it delicately, 'reluctant' to go this way. But, to reiterate, this is just my/our experience. I would really like to know if others have struggled with these issues -- and found others, more standards-compliant ways of proceeding. And also, for our work, the web services definition is one part of an overall multi-channel application design process: during development the services change constantly as more requirements are baked in. Only at the end are the services 'final' and published. Thus the key issues for us are support for rapid development / easy service refactoring. This may be a different model from others doing service design. Best -- Ian -- Ian Graham H: 416.769.2422 / W: 416.513.5656 / E: <ian . graham AT utoronto . ca> 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
