Re: Code generation or forms?

Hey Paul,

On Wed, Jun 08, 2005 at 10:03:12PM +0100, Paul Downey wrote:
> >I wonder if some use cases for the description language aren't in 
> >order?
> 
> Looking at the various DLs kicking around, there seem to be
> several services commonly used as examples:
> 
> - Norm Walsh's Where In The World:
> http://norman.walsh.name/2005/02/16/witw-part-1
> 
> - Yahoo! search services:
> http://developer.yahoo.net/
> 
> - The Atom API:
> http://www.intertwingly.net/wiki/pie/FrontPage
> 
> and I would add:
> 
> - del.icio.us API
> http://del.icio.us/doc/api
> 
> - flickr REST APIs
> http://www.flickr.com/services/api/
> 
> and other similar services abound out there, hence interest
> in describing them more formally. But as I know you're aware of
> these services, i wonder if i've just sprung a trap :-)

Heh.  Not that I don't enjoy a good trap, but that wasn't one. 8-)

Those are certainly the kind of services that we might want to
describe, but what I (personally) was really looking for was motivating
use cases for code generation, since I want to understand what folks
want to do with it.

> >Does anybody else have some use cases supporting code generation
> >requirements?
> 
> So i'll turn that round. Do you have use-cases which preclude my
> generating agents from a web-http-desc for services such as these?

Fair question.

I already gave one example about WADL's declaration of HTTP response
codes, which could easily be used to generate code inconsistent with
the HTTP specification.  Luckily, Marc clarified that this wasn't his
intent, but I think a reasonable person may have assumed otherwise.

Something else that just came to mind, was that some of the descriptive
information, while usable in a forms context, could still be used to
generate code.  Say you received some WADL which included this snippet
(from Marc's example);

<operation name="NewsSearch" method="get">
   <request>
     <parameter name="appid" type="xsd:string" required="true"/>
     <parameter name="query" type="xsd:string" required="true"/>
     <parameter name="type" type="xsd:string"/>
     <parameter name="results" type="xsd:int"/>
     <parameter name="start" type="xsd:int"/>
     <parameter name="sort" type="xsd:string"/>
     <parameter name="language" type="xsd:string"/>
   </request>
   ...

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.

Got any code generation use cases for me now? 8-)

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

Received on Monday, 13 June 2005 18:09:34 UTC