- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Mon, 13 Jun 2005 21:06:53 +0200
- To: Mark Baker <distobj@acm.org>
- Cc: Paul Downey <paul.downey@whatfettle.com>, public-web-http-desc@w3.org
On 6/13/05, Mark Baker <distobj@acm.org> wrote: > A code-generation approach to that might reasonably assume that the > name values were fixed for the lifetime of the service and therefore > hard-code them. But are they? In a forms based approach, they need not > be, and the agent may instead rely on other information such as a > "type", or data available from an associated URI (as RDF Forms does, > though I'm not sure that's best). While this can be remedied by just > specifying that names may change, I think it, and the other example > above, demonstrate that there is a line here that we need to keep in > mind and IMO, avoid crossing. Hmm, the line you describe is quite subtle. Seems rather like a variant of Cool URIs - the parameters may change but the identified service will remain the same. I think there's a similar bit of twistiness where transformations appear in the service pipeline. For example, a search query may be delivered as an (variable) XML document together with the URI of a (fixed) XSLT stylesheet to convert the XML into the target query language. The client could also require subsequent transformation of the results to get the data into a convenient format. In this kind of a situation a lot of the service description might in effect be hidden in the XSLT. Cheers, Danny. -- http://dannyayers.com
Received on Monday, 13 June 2005 19:07:01 UTC