W3C home > Mailing lists > Public > public-web-http-desc@w3.org > June 2005

Re: Caveats for Web-friendly service description

From: Leigh Dodds <leigh@ldodds.com>
Date: Wed, 01 Jun 2005 20:21:41 +0100
Message-ID: <429E0AC5.7010208@ldodds.com>
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


Received on Wednesday, 1 June 2005 19:21:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:58:32 UTC