RE: LC-Issue #230

Hi Don, group:

> The working group discussed last call issue 230 [1] in the July 10
> teleconference.  In 230, you ask that in section 3.1.1 -- 
> "Requirements on
> Features" -- the specification of a feature MUST include "1. 
> A URI used to
> refer to the feature." 
> The group would like to make sure that you were aware that 
> Section 3.2 "SOAP
> Modules" included "MUST identify itself with a URI.", and whether this
> covered your concern.  On rereading the issue, I notice that 
> you reference
> issue 203 [2], which includes this as part of the resolution, 
> so I assume
> you would still like to add URI identifiers to SOAP features as well.

That is an accurate summary, and you are correct in your assumption.  See below.

> The problem raised in the discussion of issue LC-230 is that 
> SOAP features
> may be abstract, and it might be difficult to give a 
> definitive URI to them,
> whereas SOAP modules are concrete, expressed as SOAP headers.
> It is unclear to me whether this is a valid argument.  Any 
> feedback you can
> provide would be helpful.

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 00:28:54 UTC