RE: Is it a good idea to make your WADL available?

This topic is one of many unfinished Roy conversations that I wish I had
more time for.  He is against web description languages for the reason
of increasing the coupling between systems.  I never really got to dig
into why he believes that.  

Having said that, I think that description languages make it easier to
deploy a more scalable ( in terms of # of resources) system.  

Let's take a very simple example, providing the schema type for the http
GET result of a particular URI, aka an association between a URI and
it's represenation's schema.  Most systems right now say in text things
like, "if you get this URI, you'll get back a document that meets this
particular schema".  So the developer then handcodes that association.
If the schema ever changes, then they will have to go in and change it
by hand - and they'll find out when they break.  OR if backwards compat
is preserved then there will be a new URI for a new schema that they
won't know about until they go trolling through the docs.  

If you have a description language, the association between URI and
schema for result can be automated and that includes the evolution of
the contract.  For small #s of URIs, that's might not be that big a
deal.  For large #s of resources, that becomes a big deal.  

Now I ask, "How is an automated association between representation
schema and URI more tightly coupled than a human discovered
association?"  To be clear, I'm not talking about strong-typing, I'm
talking about simply the association.  You can make either of these
strong or loosely typed by how you design the schema.  The question is
about coupling of the association itself.

I think that these are equally coupled.  In either scenario, if the
service changes the client may break or miss something.  I do think it
affects a different "property of interest", which is ease of development
and scalability of components.  

You *could* argue that having an association between URI and
represenation schema will lead people to build more brittle software
because they will do something different in their design, but I think
that's going to be a tough one to argue.  

I say yay verily, publish any and all Web Description Languages.

Cheers,
Dave

> -----Original Message-----
> From: public-web-http-desc-request@w3.org 
> [mailto:public-web-http-desc-request@w3.org] On Behalf Of 
> Mark Nottingham
> Sent: Thursday, August 31, 2006 1:03 PM
> To: public-web-http-desc@w3.org
> Subject: Is it a good idea to make your WADL available? 
> 
> 
> As I've said before, my primary use cases for WADL (and other desc
> formats) are
>    a) as a design-time aid
>    b) for documentation generation
>    c) for server and intermediary configuration and possibly 
> also for stub generation on the server side.
> 
> Talking to folks about this, I'm starting to wonder if there are
> *any* good use cases for sharing your Web description with 
> clients, because doing so risks engendering tight coupling.
> 
> The only exception I can think of right now is when you can 
> do some client-side optimisation (e.g., having hints about 
> whether the service supports chunked/compressed request 
> bodies). However, that information can be made available 
> elsewhere (e.g., OPTIONS extensions).
> 
> Thoughts?
> 
> Of course, we can't stop people from misusing description, 
> but I'd like to have the clearest, strongest guidance 
> possible available and well-known, so this doesn't lead 
> people down the same path that WS-* took (to parrot one 
> concern I've heard).
> 
> Cheers,
> 
> --
> Mark Nottingham
> mnot@yahoo-inc.com
> 
> 
> 
> 
>

Received on Friday, 1 September 2006 21:55:14 UTC