Comment 9 for bug 650967

Alternative standards: AIUI, no. Leonard and I have discussed this, driven in part by the fact that the REST community largely seems to have rejected WADL.

A nice example is http://bitworking.org/news/193/Do-we-need-WADL . I was unconvinced by some of his arguments, perhaps in part because we are using WADL, with some success AFAICT, to do what he says is unnecessary or a bad idea: generate a programmatic API on the fly. His alternative suggestions are to reuse an existing spec (ATOM or HTML, for instance), or write an RFC.

Writing an RFC is not the right solution for our use case.

Leonard and I have talked about trying to reuse an existing spec. My understanding is that this would be expensive to do, and result in something that would again need our own extensions, or at least semantics, to fully define how to construct a programmatic API from the result. IOW, it would be an expensive change for little to no benefit.

We could add the rev attributes that Leonard describes, and Manish could implement them, and there is some precedence. However, the value is questionable, in my estimation--we would be *setting* precedent by using the rev attributes in WADL this way.

From a perhaps-deceptive 10,000-foot view, I personally think Manish should keep these extended semantics out of his wadl processor, and make his C# equivalents to launchpadlib and lazr.restfulclient be aware of the containment and any other additional extra-WADL semantics we have. That's what we do in our Python code.

If adding the rev attributes makes this more palatable or easier for Manish, I'm happy to see that happen. Meanwhile, AFAIK we're already on the cutting edge, with no other way forward except those of our own devising.