Re: Code generation or forms?

Mark Pilgrim (http://diveintomark.org/projects) has numerous small  
Python wrappers around popular "Web APIs". They don't do much you  
couldn't do yourself, but they still provide a simplified view that  
makes them very easy to use.

Code like this is IMO the standard example of what one could have  
generated from a machine-readable description.

Of course you create a compile-time (or design-time) binding to the  
description this way, which introduces all kinds of problems in the  
real world; I don't see why this should not be an option for those  
who want it, though.

Stefan

--
Stefan Tilkov, stefan.tilkov@innoq.com, http://www.innoq.com
innoQ Deutschland GmbH, Halskestr. 17, D-40880 Ratingen, Germany
Phone: +49 170 471 2624  Fax: +49 2102 77160-1
ICQ: 177869128, AIM: stefantilkov, Weblog: http://www.innoq.com/blog/st/


On Jun 13, 2005, at 8:10 PM, Mark Baker wrote:

>
>
>
> 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 Tuesday, 14 June 2005 05:39:17 UTC