First, I think I want to amend my earlier proposal. I don't want
parameters in the base URI; I want the base URI to be optional because
the entire URI should be the unit of replacement. The base URI is
what defines a particular instance of a service. And, obviously, a
stub generator would require the base URI to be supplied if the WADL
description lacked one.
On 5/22/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
> Right, at some point you have bind a type of service to a concrete
> URI, there's no way round that. Currently you can do that with a set
> of WADL documents, one per instance. Your suggestion would allow a
> single WADL document plus a set of parameter values, one set of
> values per instance. I guess my question is how would a particular
> instance of a service advertise what set of parameter values it
> requires ?
They do say that no problem in computer science can't be solved by
adding a layer of indirection. WADL already did that once with the
introduction of resource_type. Or maybe do the indirection at the
top-level, where application could have attributes for a base URI and
href to another WADL description?
> An alternative would be for wadl2java to generate an additional
> constructor that would let a client application set the base URI
> dynamically. Would that cover your requirement ?
Only if I define my requirement as "wadl2java should support
location-independent services." But I'm a pain in the butt (um, a
principled individual), so my requirement is that WADL should support
location-independent services (because it's about the spec, not about
any particular implementation). I don't want to complain about
wadl2python, wadl2c++, etc..
joe