"WADL schema is just too flexible and ambiguous for any tool to traverse and generate the code/assembly."
Exactly. WADL is explicitly not designed as a substrate for generated code. It's a guide to the documents served by the web service, describing how they link to each other and how you can use them to formulate your HTTP requests. I think we've talked about this before, but it bears repeating.
I suspect you want something like WSDL: a document that uses a standardized type system to describe a distributed object model which you can map onto client-side classes in a statically compiled language.
The main anti-WADL argument is that WADL is just a friendlier version of WSDL, a way of writing programmatic "API" clients instead of web-browser-like clients that just process documents. The trend, insofar as there is a trend, is away from documents that describe anything resembling client-side data structures, and towards documents that describe *themselves*, the way HTML documents do. (At this point, the main alternative to WADL is HTML5.)
You're understandably concerned about putting Launchpad-specific code in your WADL tool. I would say that by introducing any notion of "collection" into your tool, you've already introduced Launchpad-specific code. WADL doesn't define "collection", so of course it doesn't define "type of the collection". We respect this distinction by keeping collection-aware code in lazr.restfulclient, not in wadllib.
Now, using our WADL as though it were WSDL should be possible, because the documents we send _do_ correspond pretty closely to classical data structures. We *do* serve collections, and each collection *does* have a homogenous "type". And I've done what I can to express these facts using WADL's vocabulary.
WADL makes it easy to point out the interesting parts of a document, and so I'm able to say: "if you look *here* in the bug-page document, you'll find a bunch of links to bug documents". That's my way of saying "a bug-page is a collection of bugs". I can't say that that's what bug-page "is", because as far as WADL is concerned, a bug-page is just a JSON document that contains certain links.
There's some more I could do to distinguish the various links from each other--that's the rel/rev stuff I've talked about earlier in this bug. But if you want a "collection" that has a homogenous "type", you'll either need to hard-code those ideas into your code, or become comfortable with relating documents to each other through their rel and rev attributes.
"WADL schema is just too flexible and ambiguous for any tool to traverse and generate the code/assembly."
Exactly. WADL is explicitly not designed as a substrate for generated code. It's a guide to the documents served by the web service, describing how they link to each other and how you can use them to formulate your HTTP requests. I think we've talked about this before, but it bears repeating.
I suspect you want something like WSDL: a document that uses a standardized type system to describe a distributed object model which you can map onto client-side classes in a statically compiled language.
The main anti-WADL argument is that WADL is just a friendlier version of WSDL, a way of writing programmatic "API" clients instead of web-browser-like clients that just process documents. The trend, insofar as there is a trend, is away from documents that describe anything resembling client-side data structures, and towards documents that describe *themselves*, the way HTML documents do. (At this point, the main alternative to WADL is HTML5.)
You're understandably concerned about putting Launchpad-specific code in your WADL tool. I would say that by introducing any notion of "collection" into your tool, you've already introduced Launchpad-specific code. WADL doesn't define "collection", so of course it doesn't define "type of the collection". We respect this distinction by keeping collection-aware code in lazr.restfulclient, not in wadllib.
Now, using our WADL as though it were WSDL should be possible, because the documents we send _do_ correspond pretty closely to classical data structures. We *do* serve collections, and each collection *does* have a homogenous "type". And I've done what I can to express these facts using WADL's vocabulary.
WADL makes it easy to point out the interesting parts of a document, and so I'm able to say: "if you look *here* in the bug-page document, you'll find a bunch of links to bug documents". That's my way of saying "a bug-page is a collection of bugs". I can't say that that's what bug-page "is", because as far as WADL is concerned, a bug-page is just a JSON document that contains certain links.
There's some more I could do to distinguish the various links from each other--that's the rel/rev stuff I've talked about earlier in this bug. But if you want a "collection" that has a homogenous "type", you'll either need to hard-code those ideas into your code, or become comfortable with relating documents to each other through their rel and rev attributes.