All of the XSDs produced so far use XSD 1.1.

-jOrGe W.

On Jun 15, 2012, at 8:57 AM, Christopher B Ferris wrote:

+1

Over-reliance on WADL will only make it more challenging to gracefully evolve
the APIs such that implementations can be forwards and/or backwards compatible,
especially when exchanging XML based on an XSD that is not carefully crafted
with proper extensibility points incorporated throughout the schema design,
unless we were to adopt XSD1.1 which has an optional open content model (but
which has not yet seen wide adoption, sadly).

Cheers,

Christopher Ferris IBM Distinguished Engineer, CTO Industry and Cloud Standards Member, IBM Academy of Technology IBM Software Group, Standards Strategy email: chri...@us.ibm.com<mailto:chri...@us.ibm.com> Twitter: christo4ferris phone: +1 508 234 2986

-----openstack-bounces+chrisfer=us.i...@lists.launchpad.net<mailto:-----openstack-bounces+chrisfer=us.i...@lists.launchpad.net>
wrote: ----- To: "Nguyen, Liem Manh" <liem...@hp.com<mailto:liem...@hp.com>> From: Mark Nottingham Sent by:
openstack-bounces+chrisfer=us.i...@lists.launchpad.net<mailto:openstack-bounces+chrisfer=us.i...@lists.launchpad.net> Date: 06/14/2012 08:34PM Cc: "open...@lists.launchpad.net<mailto:open...@lists.launchpad.net>"
<open...@lists.launchpad.net<mailto:open...@lists.launchpad.net>> Subject: [Openstack] WADL [was: v3 API draft (update and questions to the
community)]

Hi Liem,

I'm one of the folks who helped Marc get WADL off of the ground. At the time, my
use cases were exactly as you describe: documentation (e.g.,
<https://github.com/mnot/wadl_stylesheets>) and testing.

Even back then, there was a lot of discussion in the community; e.g., see: http://bitworking.org/news/193/Do-we-need-WADL http://old.nabble.com/Is-it-a-good-idea-to-make-your-WADL-available--tc6087155r1.html http://www.25hoursaday.com/weblog/CommentView.aspx?guid=f88dc5a6-0aff-44ca-ba42-38c651612092

I think many of the concerns that were expressed then are still valid -- some
even within these limited uses. In no particular order:

* People can and will use WADL to represent a "contract" to a service (really,
an IDL), and "bake" client code to a snapshot of it in time. While it's true
that the client and server need to have agreement about what goes on the wire
and what it means, the assumptions around what guarantees WADL makes are not
well-thought-out (in a manner similar to WSDL), making clients generated from it
very tightly bound to the snapshot of the server they saw at some point in the
past. This, in turn, makes evolution / extension of the API a lot harder than it
needs to be.

* WADL's primitives are XML Schema datatypes. This is a horrible match for
dynamic languages like Python.

* WADL itself embodies certain patterns of use that tend to show through if you
design for it; these may or may not be the best patterns for a particular use
case. This is because HTTP and URLs are very flexible things, and it isn't
expressive enough to cover all of that space. As a result, you can end up with
convoluted APIs that are designed to fit WADL, rather than do the task at hand.

From what I've seen, many developers in OpenStack are profoundly uninterested in
working with WADL. YMMV, but AFAICT this results in the WADL being done by other
folks, and not matching the reality of the implementation; not a good situation
for anyone.

What we need, I think, is a specification of the API that's precise,
unambiguous, and easy to understand and maintain. I personally don't think WADL
is up to that task (at least as a primary artefact), so (as I mentioned), I'm
going to be proposing another approach.

Cheers,

On 15/06/2012, at 2:08 AM, Nguyen, Liem Manh wrote: