RE: LC-Issue #230

Thanks, Glen.  I'm convinced.

+1

> -----Original Message-----
> From: Glen Daniels [mailto:gdaniels@macromedia.com]
> Subject: RE: LC-Issue #230
>
> You can give a definitive URI to anything! :)  In particular, 
> the features that we describe in the SOAP 1.2 Adjuncts spec 
> already have URIs, and I want that practice to be normative.  
> Here's why:
> 
> Imagine a hypothetical description language which allowed you 
> to say something like:
> 
> <abstractService name="addTwoNumbers">
>   <feature required="true">
>    http://www.w3.org/2002/06/soap/mep/request-response/
>   </feature>
>   ...
> </abstractService>
> 
> This would let someone know that the (abstract) 
> request-response MEP was needed by this particular service, 
> but NOT how in particular it should be expressed.  Software 
> reading this description might find that later on, we 
> discover that the HTTP binding for SOAP 1.2 is in use - 
> problem solved, as that binding already implements the 
> feature.  On the other hand, we might find that the 
> "soap-over-udp" binding is in use.... at that point a number 
> of things might occur:
> 
> 1) We have a number of soap modules available, one of which 
> claims to implement that feature, so we engage it 
> automatically (i.e. mustUnderstand headers get added to the 
> message to implement the MEP)
> 
> 2) A SOAP module is explicitly specified in the 
> binding-specific section of the description.
> 
> 3) We can fail because we know up-front that we don't have a 
> way to satisfy that required feature.
> 
> Ensuring that feature specs have URIs allows us to not only 
> describe them as above, but also to unambiguously refer to 
> them in other documents (module specifications, for instance) 
> and to have a "hook" to hang things like RDF assertions on as 
> well.  I'll also note that best-practice naming of the 
> properties associated with features/modules will also allow 
> *them* to be accurately described, referred to, and bound to 
> concrete instances.
> 
> IMHO, this is important stuff for the future of Web Services.
> 
> Thanks,
> --Glen

Received on Thursday, 11 July 2002 10:32:07 UTC