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

I wasn't present at the drafting of the original charter, but just from 
reading the text, the term "including" in

   4. Abstract properties to identify subsequent destinations in the
      message exchange, including:

    * the reply destination,
    * the fault destination.

clearly means "including but not limited to", particularly in 
conjunction with the non-specific "subsequent destinations"

By contrast, the status quo better fits a requirement of the form

   4. Abstract properties to identify

    * the reply destination,
    * the fault destination.

As to "The components must be extensible to enable other mechanisms 
...", I don't see how it's relevant that EPRs are extensible.  Extending 
EPRs does not add a new MAP, particularly since it will be the sender 
that wants to add MAPs for subsequent destinations, and the EPR it is 
sending to is meant to be opaque to it.  As it stands, MAPs are 
specifically /not/ extensible, and that is the component that would have 
to extend to cover arbitrary combinations of subsequent destinations.

In short, I don't see how this section of the charter can be met without 
an extensibility point in MAPs allowing for an arbitrary set of 
subsequent destinations (which is not required to include reply or fault 
endpoints).

Saying that one can always add more SOAP headers doesn't look like an 
answer to me, but perhaps a fully worked-out example from someone 
advocating this approach would help to clarify.  On the surface it seems 
no better than saying that XML supports asynchronicity because you can 
use XML to convey information about endpoints.

Mark Nottingham wrote:

>
> [ 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
>
>