- From: Jan Algermissen <jalgermissen@topicmapping.com>
- Date: Sat, 10 Jun 2006 17:45:50 +0200
- To: "Mark Baker" <distobj@acm.org>
- Cc: "Tim Bray" <tbray@textuality.com>, "Paul Denning" <pauld@mitre.org>, public-web-http-desc@w3.org
On Jun 9, 2006, at 4:18 AM, Mark Baker wrote: > > On 6/7/06, Tim Bray <tbray@textuality.com> wrote: >> [...] When building a heterogeneous distributed >> system, I'd like to have a contract that operates at a higher level >> than a MIME type, so that when things break, you can finger-point >> constructively. -Tim > > Sorry, I don't understand what you mean by that. > Assuming a business context and the use of XSD, I think Tim is saying that a MIME type would usually define some set of business object types (e.g. person, invoice) including relationship semantics. I think he'd expect a resource that accepts data submission via POST to explicitly state what the type of the objects is, that it accepts as input (e.g. "I'll take XML input that conforms to the person content model of the XSD"). This infomation can be used by developers at design time to know that they are expected to consruct a person object and send it off. If the resource just says that it accepts the MIME type then you do not get that information (that contract), all the client developer can know is that it must send that MIME type - but what kind of message?? If the resource some time receives an invoice instance, you'd know that the contract of "needing a person" has been violated. The same applies to the server on day switching to accept invoices, but not persons anymore. Does that clarify? Jan > Mark. >
Received on Saturday, 10 June 2006 15:46:01 UTC