From: Geoff Lane <geoff@...>
Date: 2006-02-25T03:18:14+09:00
Subject: Re: Creating Ruby Classes from XSD?

Henrik Martensson wrote:
> On Fri, 2006-02-24 at 14:27, Geoffrey Lane wrote:
>> Yep, that's the exact idea. You don't only want to be tightly-coupled  
>> to the data specification, you want it to be EXACTLY the same. The  
>> most common place this is used is in SOAP Web Service design. It's  
>> often called contract first or schema first design. It's not a bad  
>> thing to be tightly coupled to your data at that point because the  
>> whole idea is to be able to interoperate with an existing service.  
> 
> My point is that you are tightly coupled to somebody elses data. This
> means your application is very vulnerable.
> 
> SOAP does have a lot of problems because of this. REST offers a more
> flexible alternative.
> 
> Tight coupling isn't necessarily bad - a lot of the time nothing
> changes, and then everything works. On the other hand, why take the risk
> if there is no great benefit? Sometimes things do change. then things
> get expensive.
> 
>> This is all about sharing, and it's nice to make things easy and  
>> language-neutral when you're going to share. (Cue up Mr. Rogers theme  
>> music.)
> 
> Also, when sharing, it is important to be flexible. In this case, the
> flexibility doesn't really cost you anything, because using a generic
> data model is just as easy as using a customized one. Sometimes it is
> even easier.
> 
>> XSD schema (for all of its imperfections) has the ability to specify  
>> constraints on the data that help validate it. Up front your service  
>> can define things like:
>>
>> (pseudo-XSD)
>> US Address:
>>   Street1 = required
>>   Street2 = optional
>>   City = required
>>   State = [A-Z]{2}
>>   USZip = [0-9]{5}(-[0-9]{4})?
>>
>> Those kinds of constraints can be done in code, but no language I  
>> know of can make an interface to a method that explicit.
> 
> You can do it in W3C XML Schema and in RELAX NG. In principle, you can
> do it with NOTATIONs in a DTD, if only two people could ever agree on
> what a NOTATION declaration means.
> 
> I do like your example. Suppose the addresses are in a customer
> database, and the company that owns it expands its operations to Europe.
> They will then need to extend their data format so that they can handle
> the addresses of European customers, so they add a country field, and a
> zip code field that isn't U.S. specific. While they're at it, they add
> fields for phone number, fax, mobile, email, and web site. Seing that
> the Street2 field isn't very useful, they remove it.
> 
> If you have built a client in the U.S. that queries the database, and
> maps the result to an object model generated from a schema, your
> application will now go KABLOINK! If your application uses REXML, SAX or
> DOM, it can just ignore the extra information and keep working smoothly.
> 
> /Henrik
> 

In general, I'm not worried about this because things like Schema have 
the ability to support optional entities so you can grow your schema 
over time. Schema is flexible so that growing to another Address format 
would not be difficult and people could still use the US format. You can 
provide <xsd:choice> elements to provide multiple valid options for a 
single entity. (OK, I'll quit now) People also generally do things like 
versioning of Schemas to handle breaking changes.

Also, don't get me wrong. I'm not saying it's a good idea to query a 
database directly into an interchange format like SOAP. You are totally 
correct that it is often a good idea to decouple a service layer from a 
data layer, from a business layer. But using generated code for a 
Service layer can be very helpful.

There's nothing wrong with REST, but you're implying that you can change 
a REST service at any time and all the clients will still work? That's 
just not true. If you make enough changes, you're going to break calling 
clients. The service has some basic expectations. That's true of REST 
and of SOAP.

Don't mean to beat a dead horse with this one. SOAP is a tool, just like 
many others. If I'm going to go through the trouble of doing SOAP, I do 
Document Literal services because I can get full Schema validation from it.

-- 
Geoff Lane <geoff@zorched.net>