- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 14 Jun 2005 18:35:51 +0200
- To: <hughw@wellstorm.com>
- Cc: "'Paul Downey'" <paul.downey@whatfettle.com>, <public-web-http-desc@w3.org>
OK. I would fully support a documentation (or similar) function to allow humans to interpret the semantics of the interface, either at design time or runtime (depending on the use case). Designing in semantics for machines is less interesting to me at this point, in that I think that effort will take a considerable amount of time and careful thought, and there are some real low-hanging fruit we can grab in the meantime. Of course, what we do should be able to be extended to add machine-readable semantics (much as WSDL-S attempts to do for Web services). On Jun 14, 2005, at 5:48 PM, Hugh Winkler wrote: > > >> >> 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 >> > > > > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 14 June 2005 16:36:06 UTC