- From: Leigh Dodds <leigh@ldodds.com>
- Date: Wed, 01 Jun 2005 20:21:41 +0100
- To: Tim Bray <tbray@textuality.com>
- Cc: Marc Hadley <Marc.Hadley@Sun.COM>, Mark Baker <distobj@acm.org>, public-web-http-desc@w3.org
Tim Bray wrote: > On Jun 1, 2005, at 7:48 AM, Leigh Dodds wrote: > >> Can I suggest that a requirement for a service description format >> ought to allow for both RDF and XML as representation formats? > > Why? The cost of supporting two completely incompatible representation > formats is high, so the corresponding benefit would have to be high > too. -Tim From the opening list message [1]: "this mailing list is dedicated to discussion of Web description languages based on URI/IRI and HTTP, and aligned with the Web and REST Architecture." This is inclusive of all REST style services no matter what kind of representations they return. So such a description language ought to aim for being representation neutral. Personally I think XML and RDF are the most likely candidates, but there's nothing that follows from current web or REST architecture that mandates that. I recently reviewed a whole bunch of different RESTful services. The majority returned XML. Some supported RDF, others even plain text. Why assume that services will always return plain old XML? The most I'd expect to see about representation forms in a service description is some indication of the schemas/vocabularies included in a given response. The client may then select among possible representations of a given resource according to its capabilities. Binding response elements to particular purposes seems like an additional use case. Perhaps this can be supported by extension elements. L. [1]. http://lists.w3.org/Archives/Public/public-web-http-desc/2005May/0001.html
Received on Wednesday, 1 June 2005 19:21:51 UTC