RE: Code generation or forms?

The following snippet is one of the reasons why WDL uses XML Schema
types for the request parameters, as Schema has well defined (if needing
of improvement) constructs for controlling extensibility and versioning.

In WDL, the NewsSearch request could have a schema wildcard that allowed
extensibility.  Then any code-generation would know that more stuff
might appear.

> Something else that just came to mind, was that some of the
> 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
> 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.


Join CEO Alfred Chuang and CTO Mark Carges on June 15 for a unique online 
event, giving you the first look at a new category of enterprise software 
built specifically for Service-Oriented Architecture (SOA).

Register Now.  It's Free!

Received on Monday, 13 June 2005 22:02:11 UTC