- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Thu, 02 Jun 2005 19:07:22 +0200
- To: Mark Baker <distobj@acm.org>
- Cc: public-web-http-desc@w3.org
- Message-id: <C58A3E22-3009-4A66-A955-4F3FBE65C854@Sun.COM>
On Jun 2, 2005, at 4:12 PM, Mark Baker wrote: > >> In WADL the fault elements are intended to specify an inclusive >> rather than exclusive list. >> > > Ah, ok. You might want to say that in the spec. 8-) > Will do, I thought I had but reading what I wrote its doesn't come across too clearly :-(. > So that would no longer break HTTP, which is good. I'm still not > seeing a whole lot of value there though, but perhaps I'm not > looking hard enough. Which brings me to ... > > >>> Another example of this is the use, in most of the description specs >>> I've seen, of XML schema. For the same reason as above, I generally >>> think it's a bad idea to describe the data produced using a schema >>> since schemas generally (DaveO's excellent extensibility advice >>> notwithstanding) change foreseeably over time, and I don't want a >>> change >>> in the schema produced by a service breaking clients if I can >>> help it. >>> Instead, I'm more a fan of simply using a media type as a name >>> for an >>> open-ended sequence of backwards-compatible schemas (think "text/ >>> html" >>> vs. HTML 2.0, 3.2, 4.01, etc..), as well as, of course, >>> associating an >>> extensible processing model to that media type to accomodate as many >>> unanticipated extensions as possible over time. >>> >>> >> Paul Downey and I discussed this over a few beers last night. I think >> there's a tension between providing a loose description that is more >> open to evolution but less useful in terms of code generation and a >> description that is tighter but more useful for code generation. >> > > Agreed, but ... > > It sounds like the ability to generate code from these descriptions is > an objective for you, right? As I mentioned, I'm personally > interested > in having these descriptions consumed at runtime, since I think that's > far higher value ("more open to evolution", as you say). > > Do you think that a single description document could be used both at > runtime and design-time? Or would it make sense to have two different > documents? I'm undecided, mostly because I don't understand what > it is > that folks want to accomplish with code generation. I suppose WADL is > a bit of both - have you got any experience using it at both design > time > and runtime that you can relay? > I've only really experimented with code generation, one of my internal metrics for WADL was that it should be possible to generate Java and Python using XSLT without being some kind of XSLT guru (which I'm most definitely not). I don't see why the same description couldn't be used for runtime config, I'm not sure the requirements are that different. Marc. --- Marc Hadley <marc.hadley at sun.com> Business Alliances, CTO Office, Sun Microsystems.
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Thursday, 2 June 2005 17:07:22 UTC