Re: Caveats for Web-friendly service description

Philippe Le Hegaret wrote:

>>This is inclusive of all REST style services no matter what kind of 
>>representations they return.
> Correct, but note that it's about languages in general, i.e. it does not
> preclude to have only one. I would agree with Tim here and be worried
> about the cost of trying to do so. We already excluded SOAP messages for
> example.

OK, I understand the concerns, and must admit to not having considered
progress towards multiple languages. But I'm not (yet) convinced that
multiple languages are required.

> There is also a different cost in simply supporting "application/rdf
> +xml" or supporting a complete mapping RDF<->Object.

Agreed. Perhaps this is another area that needs fleshing out: is the
format intended to support mappings to object models, or just a
description of a service? Supporting the former for multiple 
representations would be a lot of work I guess, the latter less so.

The latter feels more RESTful in that it involves less coupling.

> So, I wouldn't sign a requirement to allow for both RDF and XML without
> ensuring that we are not going to increase the cost by a factor of 10.


> Look at it the other way around: if you were to describe a description
> language/ontology for RDF services and I would come up with a
> requirement to support plain XML as well, would you accept it that
> easily?

I'd listen at least! :)

Point taken though. I'm not riding any hobby horses here: I'm 
writing/using/deploying both RDF and XML based services, for a variety 
of clients where representation-object mappings aren't that important.
I'm just interested to see if there's a sweet spot that will do
just enough to supporta range of implementation styles.


Received on Wednesday, 1 June 2005 20:14:34 UTC