- From: Miles Sabin <miles@mistral.co.uk>
- Date: Wed, 27 Mar 2002 00:29:25 -0000
- To: <www-tag@w3.org>
Jeff Bone wrote, > The motivation for SOAP-RPC seems reasonable at first glance: the > typing system of HTTP is so general (particularly -wrt- > representations) and coarse grained that it's not useful for > building traditional fine-grained, tightly coupled objects and > types; it's not clearly useful in modeling applications domains the > way we do today. However this ignores the fact that there's "power > in large values" and that going to smaller, fine-grained interfaces > with more specific types produces tighter coupling and non-linear > growth of compositional complexity. I don't think it's anything like that clear cut. Types don't merely have complexity costs, they have complexity benefits as well. A type is a constraint: it sets bounds on the range of acceptable values of any instance of that type, and as such _reduces_ complexity. In many cases we have a simple trade off: packing information into values vs. packing information into types. In some cases the trade off will favour weak types and rich data; in others it will favour strong types and thin data. But in neither case have we magic'd complexity away. Ultimately we'd just moving be the same stuff around ... squeeze the balloon in in one place and it'll bulge out in another. Pragmatically that might be a win, because hopefully we'd have moved problems closer to the most appropriate place to solve them. But pragmatism is really all we really have here, not the grounds for choosing an overarching philosophical system. In particular, I'd say that where there's a non-linear growth of complexity in a large strongly typed system, there'd be an corresponding growth of complexity in the equivalent large weakly typed system. The only difference is that complexity would appear elsewhere: most likely in the processing at nodes as opposed to in the communication between nodes. You pays your money and you makes your choice. Cheers, Miles
Received on Tuesday, 26 March 2002 19:29:26 UTC