[
Lists Home |
Date Index |
Thread Index
]
Michael Champion wrote:
> On 10/28/05, bryan rasmussen <rasmussen.bryan@gmail.com> wrote:
>
>>On 10/28/05, Tech Rams <techmailing@yahoo.com> 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>
|
