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"/>
    - an output-input interaction defined via : <interaction 
mep="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" node="requester"/>
    - an output-input interaction defined via: <interaction 
mep="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"/>
    - an output-input interaction defined via: <interaction 
node="rr:receiver" xmlns: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