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