OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Non-schema approach to web service design: comments?

[ 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>




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS