Charter requirements [was: Process requirements for going to Last Call]

[ Marc and Gudge, a question for you at the bottom ]

The WG is required, when it goes to Last Call, to determine whether it 
believes it has met its chartered requirements, and if it hasn't, 
explain why.

Since we hope to go to Last Call on the Core and SOAP Binding documents 
soon, here are some initial thoughts. Note that we only have to agree, 
as a WG that we *believe* these requirements to be met; we do not (yet) 
have to prove that they are.

> 2. Abstract message properties which include:
>  - a message identifier [1];

Requirement satisfied by the [message id] property in the Core.

>  - a URI for the destination address [2];

Requirement satisfied by the [destination] property in the Core. Note 
that this is now an IRI.

>  - a URI designating the action to be taken at the destination [3];

Requirement satisfied by the [action] property in the Core. Note that 
this is now an IRI.

>  - the correlation with other message(s) [4];

Requirement satisfied by the [relationship] property in the Core.

>  - the nature of the relationship with those messages [5].

Requirement satisfied by the relationship type IRI in the 
[relationship] property.

> 3. An XML Infoset [6] for communicating the information necessary to 
> generate  appropriate headers to direct messages to a service or an 
> agent including:

Requirement satisfied by Section 2.2 of the Core ("Endpoint Reference 
XML Infoset Representation")

>  - a URI designating the destination address [7];

Requirement satisfied by  /wsa:EndpointReference/wsa:Address in Section 
2.2 of the Core. Note that this is now an IRI.

>  - service specific message headers [8];
>  - interaction specific message headers [9];

Both requirements satisfied by 
/wsa:EndpointReference/wsa:ReferenceParameters in Section 2.2 of the 
Core. Note that this mechanism does not distinguish between these two 
use cases in its syntax or operation.

>  - WSDL definitions relevant to this service [10];

Requirement satisfied by /wsa:EndpointReference/wsa:Metadata and the 
content therein (defined in the WSDL document, which we'll get to 
later).

>  - additional metadata as required [11].

Requirement satisfied by  /wsa:EndpointReference/wsa:Metadata  
/wsa:EndpointReference/{any} and  /wsa:EndpointReference/@{any} in 
Section 2.2 of the Core.

> Note: the Architecture of the World  Wide Web, First Edition indicates 
> that distinct resources must  be assigned to distinct URIs. This must 
> be considered when refining the mechanism for the service specific 
> message headers [12].

Requirement satisfied in the resolution of i001.

> 4. Abstract properties to identify subsequent destinations in the 
> message  exchange, including:
>  - the reply destination [13],

Requirement satisfied by the [reply endpoint] property in the Core.

>  - the fault destination [14].

Requirement satisfied by the [fault endpoint] property in the Core.

> The components must be extensible [15 ]to enable other mechanisms such 
> as new kinds of relationships between correlated messages, policies, 
> or service semantics to be built upon Web Services Addressing.

Requirement satisfied by Section 2.5 in the Core ("Endpoint Reference 
Extensibility").

> The components must also be usable independently of the SOAP or WSDL 
> version in use [16].

Requirements satisfied by the resolution of i019.

> In addition, the Working Group is chartered to define:
>   A. A binding of all abstract message properties to SOAP 1.1 and SOAP 
> 1.2  headers. [17]

Requirement satisfied by the SOAP Binding document.

>   C. A security model for using and communicating these abstract  
> properties. [18]

Requirement satisfied in the Security Considerations sections of both 
documents.

> The components must be defined so as to allow binding to protocols 
> other than SOAP. [19]

Requirement satisfied by the separation of the Core from the SOAP 
Binding.

> The deliverables for the SOAP 1.1 and WSDL 1.1 bindings must include 
> language that the bindings are defined for backward compatibility 
> only. [20]

Marc/Gudge, I thought we'd done this -- I don't see anything in the 
SOAP Binding doc. Am I missing it?

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Tuesday, 15 March 2005 22:27:27 UTC