Re: Code generation or forms?

On 13 Jun 2005, at 19:10, Mark Baker wrote:
> 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.

I used to think I was a reasonable person, but I guess I've been mutated
by being exposed to WSDL's open world view of faults, so I didn't assume
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?

Er, fixed is a bit strong. The service will continue to accept these
values as input for its lifetime, well yes, otherwise it's a 
non-compatible
change and will break existing clients, be they dynamic or code 
generated.

> 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.

I think incompatible changes are going to cause problems regardless
of if the code is generated or more dynamic agent is involved. All
being dynamic does is to typically shorten the window between getting
the description and sending the data:

I go to buy a book from Amazon, fill in their form, but then realise
i left my credit card at the office. An hour later, back from work
I complete the form. If in the meantime Amazon change the service
in an incompatible way, my request will fail.

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

yeah, I actually wrote this Email using Perl print statements.
Can't you tell :-)

> --
http://blog.whatfettle.com

Received on Monday, 13 June 2005 21:43:00 UTC