Re: Definition of an abstract mep

IMO, the two approaches should have the same WSDL component model:
    - add a "pattern" property which in #1 is serialized as a pattern 
uri attribute, in #2a is serialized via two attributes (a mep uri 
attribute and a node name attribute) and in #2b is serialized as an 
attribute (node name) qualified by the mep uri.
I think that in #2, the mep uri and the node name should be embbeded in 
a single property because the node name has no real meaning without the 
mep uri.

The main difference between the two approaches is that the "mep/pattern" 
would be defined differently whether following #1 or #2. Option 2 is 
more natural and scales better wrt SOAP mep work.

    Youenn

Jeffrey Schlimmer wrote:

> Youenn, do the two approaches have different component models? --Jeff
>
>  
>
> -----Original Message-----
> From: FABLET Youenn [mailto:youenn.fablet@crf.canon.fr]
> Sent: Friday, January 24, 2003 6:17 AM
> To: www-ws-desc@w3.org
> Cc: Jean-Jacques Moreau
> Subject: Definition of an abstract mep
>
>  
>
> Following on discussions at the F2F (monday morning minutes) and two 
> mails I have just read from Jacek & Glen (who seemed to agree on the 
> definition of a MEP [1] [2]), it seems to me that there is a 
> mis-understanding behind the words "abstract MEP".
> 1)
> For some, an abstract MEP specification defines the message exchange 
> pattern (request-response) and identifies the service within the spec. 
> From the SOAP request-response mep, two related "WSLD abstract MEP" 
> would then be extracted :
>     - an input-output interaction defined via : <interaction 
> mep="http://example.com/mep/in-out" <http://example.com/mep/in-out>/>
>     - an output-input interaction defined via : <interaction 
> mep="http://example.com/mep/out-in" <http://example.com/mep/out-in>/>
>
> 2)
> For others (including me), an abstract MEP spec only defines nodes 
> and  the message exchange pattern between these nodes.
> Continuing with the SOAP request-response mep, you will abstract only 
> one "WSLD abstract MEP" (uri = http://example.com/mep/rr) which 
> defines two nodes. To define the two above interactions (in-out and 
> out-in), one will refer to the abstract mep and identify the node that 
> the service will be.
> One syntax is to have two attributes, a 'mep' one and a 'node' one.
>     - an input-output interaction defined via: <interaction 
> mep="http://example.com/mep/rr" <http://example.com/mep/rr> 
> node="requester"/>
>     - an output-input interaction defined via: <interaction 
> mep="http://example.com/mep/rr" <http://example.com/mep/rr> 
> node="responder"/>
> Another syntax is to have a unique attribute pointing to the node name 
> qualified by the uri of the mep. This syntax is quite similar to the 
> approach one syntax :
>     - an input-output interaction defined via: <interaction 
> node="rr:requester" xmlns:rr="http://example.com/mep/rr" 
> <http://example.com/mep/rr>/>
>     - an output-input interaction defined via: <interaction 
> node="rr:receiver" xmlns:rr="http://example.com/mep/rr" 
> <http://example.com/mep/rr>/>
>
> AFAICS, the two approachs are equally expressive and reach the same 
> level of functionnality (the in-out and out-in patterns can be both 
> described as well as the in and out patterns).
> Comparison between the two approaches :
>     - approach 1 and 2 are equally simple at the abstract and 
> syntactic level.
>     - approach 2 conforms with the definition of what is a SOAP mep
>     - with approach 2, there are less specifications to be written 
> (with approach 1, a two nodes soap spec will map to two WSDL abstract 
> mep specs, a three nodes soap mep will map to three specs...)
>     - approach 2 allows the relationship between WSDL files to be made 
> clearer: the interaction type (i.e. 'abstract mep') would not change 
> when changing from a node (for instance an http client) to another one 
> (an http server) wsdl. Only the node name would change
>
> I do not clearly see the advantages of approach 1. Does anybody want 
> to list them ?
>
>     Youenn
>
> [1] :  http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0071.html
> [2] : http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0032.html
>