RE: Code generation or forms?

> 
> I think we're talking about how people use the format here, rather than
> the format itself. Can someone show (e.g., with examples) how code
> generation vs. forms surfaces in the format itself?


A forms language has to indicate the semantics of each parameter so that an
intelligent agent can interpret them and know how to put the right value in
the right field. In the case of HTML forms that intelligent agent is a
human, and the semantic instructions are encoded in natural language
accompanying the form: "Name", "Address", "Date of birth".

Natural language instructions are OK when the intelligent agent is expected
to be a human operating a browser or other user agent. If you had an XML
form you could define a description tag or attribute that would do the trick
-- just imagine WADL like <parameter name="appid" type="xsd:string"
required="true" description="The application id" />. In a forms language
this description is not a "nice to have"; it's essential so that a client
program can display it to the user. In a code generation scenario, this
description is optional, or need not be formalized, since it's only the
programmer, reading the service documentation at design time, who needs to
understand the meanings of the parameters.

If the intelligent agent on the client side is a machine, then you have to
get pretty fancy with your semantic description of what parameters mean. I
think Jan earlier suggested allowable RDF graphs.

Hugh




















> 
> I have been assuming that I'll be using the format to inform the
> runtime behaviour of the application, and WADL (for example) seems to
> support this. Is there some what it doesn't?
> 
> 
> On Jun 14, 2005, at 3:48 PM, Hugh Winkler wrote:
> 
> >
> >> On 14 Jun 2005, at 05:29, Hugh Winkler wrote:
> >>
> >>>
> >>>>
> >>>> If the service suddenly expects the client to send the credit card
> >>>> number using a different parameter name,
> >>>
> >>> No, that wouldn't break using forms. The form sends down the
> >>> parameter
> >>> name
> >>> to use for passing the credit card number.
> >>
> >> Er, I could use that argument for any self describing format
> >> including XML
> >>
> >> --
> >
> > Yes, if you augment the XML with rules -- a forms description language
> > --
> > instructing clients how to process the tags.
> >
> >
> > The point being that the "forms description" approach would be more
> > robust
> > against this kind of change, than the "code generation" approach.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> --
> Mark Nottingham   Principal Technologist
> Office of the CTO   BEA Systems
>

Received on Tuesday, 14 June 2005 15:51:50 UTC