Re: Issue i021 detailed proposal (was Re: Issue 021: WSDL Extension for Addressing)

* Hugo Haas <> [2004-11-24 15:27+0100]
> This email fulfills my action item:
>   Hugo to send a refined proposal for issue 021. Due 2004-11-26.

Based on last week's discussion around issue i021, this email

    Hugo to expand on his proposal for issue 021.

Below is a list of proposed changes to the drafts:

Please note that I have below instances of "[1.0]" in the text: this
shows how the resolution of i039 would impact my proposal for i021.

> -=- 1. Identification of the our extension -=-
> I am proposing to identify the Web Services Addressing Core
> specification as a feature, which essentially means giving it a URI,
> say:
> All this means is that the spec and its semantics are unambiguously
> identified by a URI. That should not be controversial, and is used as
> the basis for step (2) and (3) below, whatever direction is chosen:
> QNames or URIs, description with open-content model or F&P.

Change the introduction to:

  This section defines the Web Services Addressing [1.0] feature,
  identified by the following URI:

  It defines the information model and syntax of message addressing

> -=- 2. Identification of the properties that a message can carry -=-
> This also affects the core spec.
> A message may carry some addressing properties. We need to identify
> them unambiguously to talk about them, e.g. in WSDL.
> Those are the MIHs plus reference properties and reference parameters,
> to which I am associating each an XML Nmtoken:
> - [destination]		->	destination
> - [source endpoint]	->	sourceEndpoint
> - [reply endpoint]	->	replyEndpoint	
> - [fault endpoint]	->	faultEndpoint
> - [action]		->	action
> - [message id]		->	messageId
> - [relationship]	->	relationship
> - reference properties	->	referenceProperties
> - reference parameters	->	referenceParameters
>   ISSUE: it's interesting that ref p's are _not_ MIHs as they do need
>   to be specified in a reply which makes them some addressing headers;
>   you also may want to specify reference properties in your WSDL, I
>   suppose. I have listed them up there for the sake of discussing
>   i021, but I believe that it is an orthogonal issue.

Still in Core, do the following changes:

Preface "Message addressing properties collectively augment" by a
section 3.1 called "Message Addressing Properties".

Add the following as introductory text:

  Message addressing properties are properties of the Web Services
  Addressing [1.0] Feature.

List [reference properties] and [reference parameters] as message
addressing properties, in section 3 of Core, after [relationship].

> With URIs, still using this same URI as a base, [action] can be
> identified with
>   Note: I would prefer to propose
> for the names, but
>   the SOAP F&P framework[1] only allows URIs AFAIK for property names.
>   However, WSDL Properties[2] are named with wsdls:anyURI's, which do
>   allow URI references after resolution of a LC issue. Maybe that's an
>   option then.

For each of the message addressing properties, in their description,

    This message addressing property is formally identified by

where PROPERTY is, for each of the property:
- [destination]			->	Destination
- [source endpoint]		->	SourceEndpoint
- [reply endpoint]		->	ReplyEndpoint	
- [fault endpoint]		->	FaultEndpoint
- [action]			->	Action
- [message id]			->	MessageId
- [relationship]		->	Relationship
- [reference properties]	->	ReferenceProperties
- [reference parameters]	->	ReferenceParameters

> -=- 3. Description of those properties in WSDL -=-
> This affects the WSDL part.

The following proposed changes are for the WSDL Binding specification.

Generalize section 3 into: "Specifying of the use of Web Services
Addressing 1.0 and Message Addressing Properties in a WSDL document"

> - open-content model description:
>   + declaring the support of Web Services Addressing: we need to
>     declare an element to identify the use of our spec:
>       <wsa:Addressing/>
>   + requiring the use of Web Services Addressing: similar to
>     above:
>       <wsa:Addressing wsdl20:required="true"/>

Add a section about: Declaring the Use or Requirement of Web Services
Addressing 1.0.

Define a <wsa:Addressing> element, whose semantics means support of
Web Service Addressing for components for which it is in scope, and
for which putting a wsdl:required="true" on means requiring the use.

Note: as I am writing this, I am wondering how close this is going to
lead us to a policy discussion when defining what the scope is.

>   + setting a property's value: this can be done with attributes and
>     elements put wherever desired, using the QNames defined in (2):
>       wsa:action=""
>     Note that if we identify properties with QNames in (2), the
>     mapping with the description in WSDL is straightforward with this
>     solution. If the F&P framework is used in (2), then we can still
>     use the open-content model here and say that wsa:action sets the
>     value of the
>     Property.

Point out that a WSDL endpoint URI sets the [destination] property,
identified by its URI.

Clarify that the @wsa:Action attribute sets the [action] property,
identified by its URI.

Introduce <wsa:ReferenceProperties> and <wsa:ReferenceParameters>
elements that can set the [reference properties] and [reference
parameters] properties.

I believe that the rest of the message addressing properties only make
sense at run time.

>  ISSUE: [editorial] as I'm writing this and I'm thinking about the
>  specification of a SOAP Action in the SOAP binding in WSDL; I think
>  that some text will need to be added in the Addressing WSDL spec   
>  about the relationship between our action and the SOAP action and   
>  their declaration.

Point out that if the WSDL SOAP binding is in use, and if a SOAP
Action URI is specified by the binding, this URI MUST be identical to
the value of the @wsa:Action attribute for the message, if Web
Services Addressing is in use.



Hugo Haas - W3C -

Received on Tuesday, 7 December 2004 05:18:25 UTC