- From: Jeff Bone <jbone@jump.net>
- Date: Tue, 26 Mar 2002 20:12:25 -0600
- To: Miles Sabin <miles@mistral.co.uk>
- CC: www-tag@w3.org
Miles Sabin wrote: > How does the receiver "party with anybody" other than by being able to > process all ten message variants that it might receive? And isn't that > just moving complexity from one place to another? Why here rather than > there? Consider a "general" type --- say, text streams ala UNIX --- vs. a "specific" type, say "class AddressBook." Now an address book can certainly be represented as a structured text stream. As such, many interesting things can be done with it even by programs which don't understand class AddressBook: the lines can be counted, it can be searched for occurrances of "Sabin," etc. Representing an address book as a text stream doesn't prevent code that understands the address book structure from using it as such, but representing it as an instance of class AddressBook may prevent other code from using it for any purpose. Graph structures may play the same role for the Web that text streams play in the above example. None of us --- I hope --- argue about the desirability of interacting with networked resources via exchanging XML-structured data. The question is "what does that graph structure mean?" REST --- and perhaps the Web itself --- has as its fundamental paradigm exchanging representations of resource state rather than encapsulating them behind type-specific interfaces. If the XML being exchanged does *not* represent the state of the resource, then there are perhaps very generic applications of interest that cannot be usefully performed on said XML regardless of its type. This is how SOAP-RPC breaks the Web: it subverts the very notion that what's being transferred is a state representation rather than a set of parameters to some arbitrary operation. > There could be lots of answers to that last question, some of them > technical, some of them political and economic. But "because it > reduces overall complexity" isn't likely to be one of them. Again, we're talking about *compositional* complexity, here --- though there may well be more general complexity implications -wrt- implementation complexity measured in various ways, etc. The complexity we're talking about is the number of interfaces that need to be understood and supported in order to operate on any resource type. Clearly, supporting 10 different type interfaces in e.g. a caching proxy --- i.e., let's say there are 10 ways to "get" a meaningful and complete representation of resource state for 10 resources --- is more complex than supporting 1. Discouraging / disallowing that kind of type-specific interface and encapsulation obviously and incontrovertibly reduces that kind of "overall" complexity. jb
Received on Tuesday, 26 March 2002 21:25:54 UTC