Re: Code generation or forms?

Though I agree with Hugh's intent, I think his choice of words was
unfortunate for the pie-in-the-sky image I'm sure it planted in most
folks' heads.

What we're (well, me at least) really talking about here is the
difference between this;

  <parameter name="language" />

and this, where clients bind to the "application type" (my term) of the
parameter, not its name.

  <parameter name="language"
             type="http://example.org/types/language/" />

(any similarity to WADL is purely coincidental - "type" is certainly
very different)

It's just a layer of indirection which enables a client to depend on
data which is expected to change less often.  Using a URI also provides
the hook into the more advanced "semantic" features, but it needn't be
dereferenced by a non-SemWeb app (or a SemWeb app for that matter).
RDF Forms uses a URI in this way.

Mark.

On Tue, Jun 14, 2005 at 06:35:51PM +0200, Mark Nottingham wrote:
> 
> 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).

Received on Wednesday, 15 June 2005 04:49:54 UTC