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

--
http://kallokain.blogspot.com/ - Blogging from the trenches of software
development
http://www.henrikmartensson.org/  - Reflections on software development
http://testunitxml.rubyforge.org/  - The Test::Unit::XML Home Page
http://declan.rubyforge.org/ - The Declan Home Page