OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Prelim minutes of 6/29 wsrm tc teleconferences

The prelim minutes are attached.

Please provide comments by friday on the list.

Please provide you opinions on the suggested resolutions for the 
remaining three issues on the email list
before next meeting on July 6.

Tom Rutt
WSRM Chair

Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003

Preliminary Minutes WSRM TC Conference Call –June 29, 2004


The meeting of the WSRM TC took place by teleconference 

Tuesday, June 29, 2004, from 5:30 to 7:30 PM Eastern Standard Time



1         Draft Agenda:

Draft Agenda to WSRM TC Conference Call

1 Roll Call

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes –

3 Action Item Status Review

4 Discussions of unresolved comments

5 Discussion of Document progression

6 Discussion of FAQ for WS-Reliability


2         Roll Call


First Name

Last Name




Voting Level





Booz Allen Hamilton






Cyclone Commerce

















TC Chair





































NEC Corporation






NEC Corporation






Nortel Networks



































 Meeting  is  quorate.


3         Minutes Discussion

3.1      Appointment of Minute Taker

Tom Rutt will take minutes.


Minutes will serve to record issue resolutions.

3.2      Approval of previous meeting minutes

The minutes of the June 22 teleconf are posted at:



John Fuller pointed out that he did attend the meeting.  Tom Rutt will update the attendance list to indicate this attendance.


Jeff T moved, Abbie seconded to approve minutes.


No opposition minutes approved.

4         Status of Action Items


4.1      Action 052503-1 (Tom Rutt) pending

Tom took an action item to complete the status column of 
pre public review issues list, with correct URLs.


4.2      Action 060104-5 (Jacques) Pending


Action: Jacques, will propose further edits, on the FAQ for composability.


Still open



4.3      Action 062204-1 (Jacques) Closed


Action: Jacques  will propose text to resolve Binding model issue.


Jacques provided text in:



5         Discussion of Issues and editorial Comments

The following issues list includes items which need further discussion:



5.1      PC24






Doug Bunting


Title: Payload inclusion and MEPs other than request/response

Description: Re: more on payload(s) inclusion and MEPs than our Request-ResponseMEP discussion covers

Proposal: under discussion



·  Summary of WS-Reliability 1.01* issues discussed over past week
From Doug Bunting <Doug.Bunting@Sun.COM> on
13 Jun 2004 22:10:30 -0000


·  Groups - COntribution-JD-WS-Reliability-2004-06-21.pdf uploaded
From jdurand@us.fujitsu.com on
25 Jun 2004 09:33:16 -0000


·  Re: [wsrm] Groups - COntribution-JD-WS-Reliability-2004-06-21.pdfuploaded
From Sunil Kunisetty <sunil.kunisetty@oracle.com> on
25 Jun 2004 21:52:45 -0000



 I’m very un-comfortable with the new wordings.


 A Meta Point: The spec. is getting very “verbose” and complicated. If I myself  have to read couple of times to  understand the gist, understand the plight of the naïve reader.


 I do understand that the spec. has to talk about the model. But to me that has to be simple and crisp and not overly complicated. An overly complicated model implies implementation restrictions. Also, while I understand that RMP is not an independent entity and piggy backs on a SOAP processor, we should discuss about RMP  model in particular and  not SOAP Processing model in general.


 Emphasize should be more on the protocol behavior and the headers as these have an affect on the interoperability.


 To me a model description should be as simple as:

  -         Supports RM capability for request messages only

  -         Works with both request-response and one-way transports.

  -         For cases where RM-Reply has to be piggy backed on the response (such as the Response pattern case), the RMP should wait until the Consumer responds.

  -     Explain the patterns abstractly etc.


 I think we should only emphasize on the Submit and Deliver operations and avoid defining Notify and Respond.

 The way the current Notify is defined, it implies that a RMP implementation should support some kind of notification/callback mechanism to the Producer.  This is what I meant earlier when I said over emphasizing on the model could imply implementation restrictions.


 Some specific concerns about the Respond abstract operation:


  1)  We need to mention that Respond is not always there if the operation is an one way message or the message is dispatched asynchronously  (using some Queues).

   2) Even for synchronous request-response, we don’t have to wait for the Response from the Consumer in cases such as Callback  where in Response and RM-Reply are sent on different channels and we don’t have to wait for the Response to send the RM-Reply (which we send when we make available the message to the  Consumer).

  3)   And I’m very confused about the whole Correlation of the operations section (lines 266-275).  Essentially it implies (asynchronous) correlation of requests and response. This is a big NO_NO from us. Note that there could be cases where  a request-response operation could be bound 2 different one-way bindings and in that case correlating a Delivery and Respond would require some kind of correlation mechanisms as defined in WS-MessageDelivery or so. This spec. cannot stipulate search restrictions.


 Some more specific comments:

1)      Figure 1 should have dotted lines for Respond,  Return Rm-Reply and Notify.

2)      I still believe that the previous definition of Reply patterns are much better than the current ones. The  current ones talk about SOAP MEPs which is not good.

3)      Usage of word SOAP MEP is confusing as SOAP 1.1 doesn’t talk about MEP.

4)      Section 4.5 still talks about sending both SOAP and RM Fault, which is wrong and needs to be corrected

      (I do understand that your exercise is not intended to fix this but even the latest 1.03 draft has the same problem).




·  comments on Jacques Update on mep mappings
From Tom Rutt <tom@coastin.com> on
29 Jun 2004 00:19:51 -0000

Overall I think Jacques has produced the text we need to go forward.


I have some detailed comments, which are relatively minor (but important

I think) on his proposal:


Tom RUtt


Summary of Comments on COntribution-JD-WS-Reliability-2004-06-21.Pdf


 From Tom Rutt


Page: 3

line 82 : Response should be Respond


Page: 6

Sequence number: 1

line 164: why must a receiving rmp which does not support response reply

pattern have to implement the Respond primitive?


Jacques agree to remove these two normative statements.


Anish: does respond mean a payload is sent to the RMP.


Jacques: yes.


Anish what about notify: does it mean a payload is sent.


Tom: The notify is invoked whenever it has to be to convey the knowledge to the Sender.


Anish: if the sender retransmits the original request what happens.


Tom : that is another issue.


Sunil: the Notify definition should qualify the word RMP.  It is better to say a mechanism which makes available to the producer the payload or response information.


Jacques: I do agree, but I must say I do not see why this definition implies such a restriction.  The term Passes payload is intended to be abstract.


Jacques: we do not say the way it is invoked.  The arrows on the figure are the direction of data flow, not implementation.  Use term made available.


Agreed to do wordsmithing of definition of Notify, using made available terms.


Sunil: The respond operation is required for response reply pattern, where we want to piggyback reply with response.  This sentence does not clarify that it is for response reply pattern.  Here, I am worried that this implies asynchronous correlation method.  I do not want asynchronous method to deliver response, because our protocol does not support it.


Doug B: Earlier you argued that the invocation of notify should not imply who did invocation, whether it is callback or straight function call.  You seem to be asking for respond that it is a function call, why could it not be a callback in that api that maps, as described later, to something bundled with the rm reply.


Doug B: the respond operation pertains to responding to an operation over the wire.  I do not see how this


Sunil: available if exist, it does not say how the rmp got it.  It has to wait for the response, but this phase does not deal with that. 


Jacques: you have to compare notify with submit.  It is conveying from producer to sending rmp, and vice versa.  All we need to say at definition level is that the rmp must be able to correlate payload from response, with payload it has delivered.


Sunil: I want this to be specific to avoiding ambiguity that it is only for response reply pattern.


Jacques: I do not have trouble with this scoping constraint for this protocol.




Sequence number: 2

line 179: I do not understand what "thus marking the end of the

reliability contract for this message" adds to the specifiction of the

Deliver operation, especially if the request is part of a wsdl request

response operation using the response reply pattern.


Page: 9

Sequence number: 1

Line 273: wether -> whether


Jacques: section 2.2 talks about how the upper interactions are related to the lower interactions.


Doug: this 2.2 text introduces the concept of a soap processor, which is different from rmp, which is an implementation choice.  Introducing soap processor here and in later text is causing additional ambiguity.


Jacques: I did not have to do that, but I thought it would give an illustration of correlation,  I could remove that to resolve your concerns.  I wanted to state that this correlation is often provided transparently to the implementer.  We can remove that sentence.


Sunil: could we clarify this that it implies to the response reply pattern, and the two way invocation pattern.


Jacques: now that we have agreed that respond does not always have to be implemented, the wording needs to change to correspond to this restriction of the use of respond to the two way rmp invocation pattern.


Jacques: in 2.2 we have three bullet items, the respond only makes sense for the two way invocation pattern.  One way rmp invocation pattern.


Doug: I misread this whole section of text.  I thought that the rmp invocation pattern was the pattern by which it is being used, not the underlying pattern.  Is what you are saying is that if the receiving rmp knows a consumer payload is available for consumer request, we call that request response .  Respond information is pertinent only if the responding rmp knows a response payload is associated with the reliable message request received.  The implementation choices must report correlating invocation of respond with invocation of deliver.


Sunil I support that.


Jacques: The two way rmp invocation pattern should list the actual primitive invocations, and their correspondence.  The way I described these invocation patterns are mapped later on to bindings.  Are you suggesting we do not mention the sequence of operations invoked.  I would remove the bullet under 1 and keep these two next bullets.


Doug: my editorial concern is that we are making the text confusing, and overly complicated by introducing the new concept of rmp invocation pattern, rather than just describing what the consumer is getting out of this.  Maybe it is worthwhile to list the sequence of abstract operations, but we got away in the past without tying a submit with a particular deliver.  Perhaps we do not have to be quite this explicit.  Every time the word pattern is used I have to be aware of what level we are at. 


Jacques: I will try to make an abstraction of these terms.  This was mostly an editorial trick to talk about how, at user level, wsdl operation types translate to sequence of rmp operations, as well as talking about underlying soap MEPs.  I understand this concern about introducing terms at different levels.


Sunil: perhaps we can get rid of 2.2 and explain it clearly without introducing these patterns.


Jacques: we at least have to make a statement about the correlation of respond with deliver invocation.


Sunil: we do that when we discuss request response


Tom: do we need to move away from WSDL operation types for the overlying RMP interchange pattern. 


Jacques; WSDL operations map to RMP invocations patterns.  I can write this without brining in the WSDL


Doug: I think it would be easier to avoid wsdl centric terminology at either level, mostly because it is somewhat ambiguous about whether you are talking about consumer and receiving rmp interface.  We probable do not want to write down wsdl for rmp interface definitions.


Jacques: I am on vacation, I would prefer that someone else take on the rewording.  I do not have problems with the direction of this discussion.  Adding the respond primitive was the most important thing to do.  I still believe we should keep these statements abstract.  The respond should relate to a deliver operation should be an invariant, and not limited to the underling mep


Doug: while not talking about correlation between deliver and respond, we can talk about semantics of message that contain rm reply and consumer payload mapping to single notify operation.  If semantically the sending rmp treats anything in soap body as correlated with their original request, the receiving rmp has to do what is necessary to make the semantics happen.


Doug: rather than correlate a deliver and respond and a submit and notify, talk about the bind semantics of payload tied together with the request headers, or on the other side the tying consumer payload with the rm reply.


Doug: tying these primitive operations down to the semantics of the bundled messages sent down the wire.  WS reliability headers are bundled with payload by receiving rmp.  While we do not talk about correlation of submit with later notify, we do not have to talk about the correlation of deliver with later respond.


Jacques: these combinations of RM response payload, or no payload have combinatorics to be described with the reply pattern.  If we define high level operations on rmp, we should do it abstractly without implementation assumptions.  Since we have respond and deliver we need to justify it without going lower without defining how they map to message content.  That is why rmp must be able to correlate respond with deliver is a requirement.  Do we need to go further than that.


Doug: I think sunil is uncovering something important.  The current text talks about the notify as providing delivery flags for an earlier message.  It does not go into details about correlation with earlier submit operation.  Why cannot it be symmetric on the other side.


Tom: I think there is a special case on the receiving side to require the receiving rmp to generate in its reply header the message id of the message which was delivered, in the response to that message.  It needs to determine which respond payload is to be include with which referred to message id in the RM reply.


Jacques: this correlation has to take place at some level.  We have to be able to state this correlation.


Tom: I thought we had agreed that respond primitive is only used with response reply pattern.


Jacques: I think we should turn it around, The choice of using respond is given to users of rec


Doug: The correlation on sending and receiving side is symmetric.



Sequence number: 2

Line 279: add ," and a response payload (p2) to transfer in reverse,"

after "RMP2".


Page: 10

Sequence number: 1

line 301: the words "when explicitly mandated, like in the WS-I Basic

Profile" should be restated as "when explicitly specified, for

example the WS-I conformant SOAP/HTTP-POST binding ?


Sequence number: 2

Line 318: the underlying response may not always be for communicating

errors. It could be a success HTTP response, with no

soap envelope. Should be "and correlated with the underlying protocol



Page: 12

Sequence number: 1

Line 364: must -> MUST


Sequence number: 2

LIne 375: must -> MUST


Page: 16

lines 494-499: this note is obscure: All we need is the first sentence.


Page: 17

Lines 528 thru 531: Again this paragraph is obscure, Only the first

sentence is needed.


Page: 18

Lines 546 - 549: again this paragraph is obscure. Only the first

sentence is needed.


Lines 1329  to 1337 changes to section 5.2:

Jacques: I tried to abstract the mapping of the RMP invocation pattern to underlying soap MEP pattern.  We have some flexibility at this level, on how they are mapping.  We do not need more flexibility at upper layer.


Line 1338: Tom: why did you change the scope to the Input message here and in the table.


Jacques: while we talk of reply pattern which is a reply to the input message, I wanted to make it explicit that the use of reply patterns concerns the input message in this table.


Sunil: I think we need to move this section to chapter 2.  The concern I have is that the request response maps to two way RMP pattern.  We do not have to wait for the respond operation in the callback case. 


Sunil: with response reply pattern we have to wait.  It is not required for request response operations which use callback reply pattern.


Jacques: I would still only mention wsdl in a wsdl section.


Jacques: These two bullets have nothing to do with reply pattern, they only talk about mapping to underlying soap MEP.  The table might not be necessary.  Regardless to this we need to relate respond operation to wsdl operation types.


Page: 45

Line 1354: there could be a note explaining that a wsdl spec that

includes the wsrm response element as an output part bound to

the soap header is a request/response wsdl operation type.


Page: 47

lines 1410-1411: I do not understand why these two incomplete sentences

need to be added. WSRM fault codes are defined



Action: Jacques will provide another cut to try to resolve the discussion items above.  He will post a new pdf and a open office source contribution for further discussion on the email list.


All members should post detailed comments on proposed replacement text to resolve their concerns, before next week conference call.

5.2      PC25






Doug Bunting


Title: Duplicate message responses

Description: http://www.oasis-open.org/archives/wsrm/200406/msg00078.html

Proposal: under discussion



·  RE: [wsrm] clarification on Respond primitive
From Jacques Durand <JDurand@us.fujitsu.com> on
14 Jun 2004 06:19:04 -0000


·  Re: [wsrm] Discussion on Duplicate elimination issue from 6/14 minutes
From Tom Rutt <tom@coastin.com> on
28 Jun 2004 23:06:35 -0000

Tom Rutt wrote:


> I propose to allow both 1) and 3) behaviours , that is:


> 1) Sending rmp allowed to return buffered response from previous

> invocation with rm-acknolwedgement indication, or


I meant the behavour to apply to Receiving RMP for 1) above, as well as

for 3) below


1) Receiving RMP is allowed to return buffered response from previous invocation with rm acknowledgement indication, or,



> 3) define a new RM-Fault called "Response Payload Not Available for

> Duplicate request" which gets sent with

> a soap fault in the case where the duplicate invoke requires  a

> response which is not available because of duplicate request elimination.


> Tom Rutt



Doug B: I have two comments, using our current technology it is not possible to describe an optional payload.  The application level interface is either one way or two way.  Both ends should know that.  I am not sure what value this rm fault has.  The sending rmp knows it is expecting a response and it did not get it. The ack with the empty payload would say the same thing.  I would have text to strongly recommend that the receiving rmp send back any payload it is able to cache.


Tom: on the return should the soap body be empty, or contain a soap fault because the response is missing.


Doug B: wsdl 1.1 does not allow an optional response part.  I am not sure why our protocol is bound to wsdl description.  I am not sure why it matters what the response should be.  Some arguments have been that it is not a soap fault.


Sunil: The strong recommendation from Doug is fine. An ack is good enough to the sender when there is no payload.  Duplicate without ack requested does not require a reply.  If there is no ack requested, sending a fault should be allowed.  Either we can require ack requested with duplicate elimination, if we do not say that there can be cases which need a fault.


Doug B: if you did not request an ack, at the wire level it is a one way exchange, so the only way you can do is respond normally.  We have a case we are not covering well a fourth case.  When there is an RM reply expected, you use one of three patterns to get it back. When there is no ack requested and there is not rm reply would you ever return anything in the RM response.  Unless duplicate elimination is requested, and there is some way to get the payload tied with respond back to sending rmp (not yet discussed) all this text about duplicate elimination an responses is not relevant.


Sunil: I am ok to send a payload or a fault, the only minor issue is about interoperability.  A sending rmp has to accept both behaviours from a receiving rmp.


Sunil: We need to clarify if a fault can be sent if ack is not requested.  I want the fault should be sent all the time.


Doug: There may be a larger issue here.  We may have described the rm reply pattern focusing on acks, which is one half.  Do we have requirements on receiving rmp that it must use reply pattern to get fault info back to sending RMP. 


Clarify if faults are allowed/required for ack requested not asserted.


> Sunil Kunisetty wrote:


>> Tom Rutt wrote:


>>> I have one question inserted below.


>>> Tom Rutt


>>> Sunil Kunisetty wrote:


>>>> Here is the mail I sent on Duplicate Elimination a week ago.

>>>> It has the summary, possible solutions and my preferred solution.


>>>> -----------------------------------------------------------------------------------------------------


>>>> I'd like to summarize the options of using Duplicate Elimination for a

>>>> Request-Response MEP.


>>>> 1) Cache the message until the original request expires and Send the

>>>>    "payload  response" for every subsequent request.

>>>> 2)  Send an empty SOAP envelope.

>>>>      (Note that when there is no AckRequested, there won't be any

>>>> Ack and

>>>>      hence the SOAP envelope will have empty Header/body).

>>>> 3)  Send a signal that it is a "Duplicate Message".

>>>> 4)  Spec. says that this is combination is not supported.


>>>> While I personally like (4),  we can't do it as the TC voted to

>>>> support

>>>> this combination.


>>>> I'm very un-comfortable with (2) as it will cause all kinds of

>>>> issues and

>>>> as such it is meaningless/un-informative to send "empty signal".


>>>> As per (1), while it is theoritcally reasonable and easy to implement,

>>>> it is impractical from a product/solution perspective.


>>>> Here are few reasons:

>>>> (i) Potentially can throttle the server with memory being sucked up.

>>>>    Generally speaking, expire time is used optimistically and will

>>>> have a

>>>>    large life span. Caching responses that long is not too good .

>>>> (ii) I believe this thing (async. responses) is beyond the scope

>>>>    of this specification and should be handled  in the "OASIS

>>>> Asynchronous

>>>>    Service Access  Protocol TC"  [1]

>>>> (iii) There are many subtle things about caching responses:

>>>>         - there should be mechanism to invalidate the cache

>>>>         - what if the request has time sensitive information. for ex.,

>>>>           if I ask for getStockQuote for Oracle with a duration of

>>>> say 1 hr...

>>>>           Assume the first  message is lost.

>>>>           Say the RMP resent the same message after 10 mins... they

>>>> may

>>>>           get a stock quote that was 10 mins. ago.

>>>>           So if time sensitive data exists, there should be mechanism

>>>>           for data resync..


>>>> So for these reasons, I just like a RM signal [3] solution so that

>>>> the application can resend the request.



>>> The situation that causes the most trouble is when the response had

>>> been previously sent, so the responder RMP

>>> has no response payload to return since it did not invoke the second

>>> deliver. Thus the sender resending will

>>> not help all all.


>>> The reason to give an indication is so the sender will not continue

>>> to resend the duplicate, in cases where the original




>> Right. That's why I said I like to send a RM signal so that the

>> Sender can either resend the Message

>> with a different MessageId or query as you suggested.


>> Option 2 (sending an empty SOAP envelope) is the wrong thing to do.




5.3      PC26

PC26 Spec Technical Open

Sunil Kunisetty

Title: Soap Fault with RM-Fault

Description: Sunil Mail 1Sunil Mail 2Sunil Mail 3

Proposal: under discussion Resolution:



I'm cataching up with email, so I apologize upfront if this issue is


 discussed and/or resolved already.


Doug Bunting wrote:



> We have not previously discussed the second or third sentences of this

> draft.  The above changes remove some duplicate text from the second

> sentence, moves some into the first sentence and rewords the

> remainder.  If the group prefers less editorial changes and limiting

> the updates to the first sentence, I would suggest at least removing

> an extraneous "then" from the second.  The new first sentence for this

> alternative would be:


> "

> When the Response RM-Reply Pattern is in use and the message cannot

> be delivered to the Consumer, a

> SOAP Fault MUST be generated in addition to the RM Fault.

> "


 Is the above comment specific to Duplicate Elimination case or a

generic failure (to deliver) case?

 If former, then there is NO RM fault for Duplicate messages. So the

above should be better qualified as "in addition to the RM Fault if exists one".


 If it is the latter, why do we need to send *both* RM fault and SOAP

Fault. The Sending RMP will convert/translate a RM Fault either as a SOAP Exception or a API specific exception.

 So we don't need both.


 If we have to say SOAP Fault is sent, don't we need better sub-codes

for interoperability?




Tom Rutt wrote:


> whenever the request causes any rm-fault, it cannot be delivered to

> the consumer.  All RM faults

> have this property that for response reply pattern no response payload

> is avialable, unless

> the sending RMP caches prior responses.


  In this case, we will be semding a SOAP Envelope with one Header (that

has the RM Fault) and with no SOAP Body.


 The specific qn. I've is in what cases, we need to send BOTH SOAP Fault

and a RM Fault?


 I can't think of any.


Sunil Kunisetty:





> <ter> The reason to send both is that one is targeted to the sending RMP the

> other is targeted to the consumer.


> It does not hurt to send both in this case. </ter>


  I think it hurts. I'm a big proponent of not sending information when

not needed,. I believe in  not sending unnecessary and duplicate information as it will cause confusion, mutual conflict,   unnecessary bandwidth etc.


  Specifically the problems I see in this case are:

  i) The duplicate message may either be triggered by the RMP itself  or

accidentally by the application itself. Most likely by the former because of

Guaranteed Delivery. In that case, RMP itself is the consumer, so sending separate faults doesn't make much sense.

 ii) Just saying "send a SOAP Fault" is very  bad for a spec. as it is

not interoperable.

     We need to be very specific about the Fault information  to be

sent. Is it Client/Sender or Server/Receiver or what sub-code etc.?

  iii) In most cases, the Sending RMP will formulate a Fault/Exception

to the Consumer if required based on the RM fault itself. A combination of RM Fault

and SOAP Fault could be problematic in such cases as they could conflict.




Sunil: sending a fault if a wsdl does not have fault definition is not good.


Tom: why will the extra information send both ways cause confusion.


Sunil: why send extra information.  With the callback pattern, if the second message is a duplicate request/response message, what is in the original response.


Tom: the soap fault would be sent with the original response, the ws-fault would go on the callback.  The current behaviour in the document has both ws fault in header and soap fault in body for response reply pattern.  I see this as consistent.


All members, please put your opinion on this issue resolution between now and next week.



5.4      Comment on the ref Schema

No time to discuss, defer to next meeting:


·  Minor technical issue (or two) in the reference.xsd schema
From Doug Bunting <Doug.Bunting@Sun.COM> on
24 Jun 2004 15:43:22 -0000


·  Re: [wsrm] Minor technical issue (or two) in the reference.xsd schema
From Anish Karmarkar <Anish.Karmarkar@oracle.com> on
25 Jun 2004 22:10:52 -0000

Doug Bunting wrote:


> The most recent copy of this schema[1] does not seem to support (allow

> validation of) the WS-Reliability 'bare URI' scheme.  To directly insert

> text into the wsrm:ReplyTo element, the ref:ServiceRefType type must

> support mixed content.  That is,


> <xsd:complexType name="ServiceRefType">

>   <xsd:sequence>

>     <xsd:any namespace="##other" processContents="lax"/>

>   </xsd:sequence>

>   <xsd:attribute name="reference-scheme" type="xsd:anyURI" use="optional"/>

> </xsd:complexType>


> should instead be


> <xsd:complexType name="ServiceRefType" mixed="true">

>   ...

> </xsd:complexType>


> An alternative would be to leave ServiceRefType as is and define a

> particular BareURI (simple) type or element in either reference.xsd or

> ws-reliability-1.1.xsd.  Lots of options but the element would be simple

> in every case:



Good catch. I too prefer specifying a separate element/type to making it

mixed. Making it mixed will require us to specify what happens if the

content is indeed mixed -- i.e. has both CII and EII.

Defining the new element/type for bare URI just seems simpler.


> <xsd:element name="BareURI" type="xsd:anyURI">


> or


> <xsd:simpleType name="BareURIType">

>   <xsd:restriction base="xsd:anyURI" />

> </xsd:simpleType>


> <!--

>    BareURIType would be ref:BareURIType if the element were in the

>    WS-Reliability schema while the type is in the reference schema.

> -->

> <xsd:element name="BareURI" type="BareURIType">


> I lean slightly toward this second approach because it is more

> consistent with the other expected (WS-Addressing or WS-MessageDelivery,

> for example) cases.  That is, the element of ref:ServiceRefType would

> have the consistent semantics of identifying the set of messages in

> which the contained address is relevant.  The namespace of the contained

> element and the @reference-scheme value would identify the semantics of

> that address.


> Which raises another niggle I had not considered earlier: I believe the

> namespace of the contained element or the direct inclusion of text in

> the wsrm:ReplyTo element (if we leave that option) provides the same

> information as the @reference-scheme value.  Do we need both?



The reference-scheme attribute is optional. Therefore if it is

considered to be redundant for a particular addressing scheme then it

could certainly not be used (as is the case for bare uri).


Having the optional reference-scheme attribute covers the case where the

QName of the child EII does not specify the semantics of the addressing

scheme. For example, WS-MD uses the WSDL 1.1 service element as a

reference (with some restrictions on the contents of the service

element). In this case the child EII will be wsdl11:service. It is

possible that some other spec or some eventual addressing WG/TC may

decide to use wsdl:service QName but with perhaps slightly different

semantics/restrictions than WS-MD. In such a case the optional

reference-scheme attribute comes handy. So I have a slight preference

for keeping it.




> thanx,

>     doug


> [1]

> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7108/reference-1.1.xsd



6         Discussion of Document Progression.


For discussion


Could still make the CD vote at July 13 meeting.  However this will require extensive email discussions to agree on replacement text to resolve the remaining three issues by the July 6 meeting.



7         Frequently Asked Questions


Tom posted the following:


·  Approved FAQ set for WSRM TC
From Tom Rutt <tom@coastin.com> on 3 Jun 2004 13:57:21 -0000




Doug B moves to adjourn, Mark Peel seconded.


No objection, meeting adjourned at 7:34 pm.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]