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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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


Subject: RE: [ws-rx] i010 - a proposal


Doug:

That looks acceptable for allowing various distributed schemes.

I will stop the chase for a better definition, though a couple of last editorial suggestions:

-          This time in an attempt to narrow more your def, I'd add the adjective "reliable":  "For any one reliable message the endpoint that transmits the message." Or just "the endpoint that transmits a reliable message."

-          This leads me to notice that the expression "reliable message" is used a t several places (see 2.3, also Fig 1 comment) but is never defined (although one can suspect what it means) That would call for an addition to the glossary like: "reliable message: a message that complies with the reliability protocol defined in this specification". But that could be separate from your issue.

 

Regards,

Jacques                                                                                                                                                                              

 


From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, October 17, 2005 4:12 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i010 - a proposal

 


Jacques,
  sorry for the delay.  Yes I left 'endpoint' in the definitions because they refer to "the" message - implying what the sender/receiver is for any _one_ message sent.  I suppose I could change the text to make that clearer, something like:  
  RM Source: For any one message the endpoint that transmits the message.
I'm actually ok with using the term 'endpoint' when talking about one particular message exchange.
I'll fix the other two spots you pointed out.  New version of diffs is attached with all of these changes.
thanks
-Doug



Jacques Durand <JDurand@us.fujitsu.com>

10/11/2005 05:34 PM

To

Doug Davis/Raleigh/IBM@IBMUS, ws-rx@lists.oasis-open.org

cc

 

Subject

RE: [ws-rx] i010 - a proposal

 

 

 




Doug:
 
the defs of RMD and RMS still define them as "endpoints", which will maintain the confusion.
How about RMS as "implementation of this specification supporting the Send and Transmit operations, usually associated with the endpoint reference of a WS or of its client", and RMD as "implementation of this specification supporting the Receive and Deliver operations, usually associated with the endpoint reference of a WS or of its client."
 
That would just "associate" endpoints to the RMS/RMD (not excluding several endpoints, as well as not excluding several addressable RM entities cooperating as a single RMS or RMD).
 
Other places where "endpoint" is too tightly associated with RMS or RMD:
 
Line 786-789: "This fault is sent by either the RM Source or the RM Destination to indicate that the
endpoint that generated the fault..." mentions of endpoint to be removed in this paragraph too.
 
Line 1302: (Appendix B4)  "The sending endpoint discovers that message number 2 was not received..."
 
Jacques
 

 



From: Doug Davis [mailto:dug@us.ibm.com]
Sent:
Sunday, October 09, 2005 10:39 PM
To:
ws-rx@lists.oasis-open.org
Subject:
RE: [ws-rx] i010 - a proposal

 

Per my AI for issue 10 here's what I came up with.

As much as I tried I really couldn't find a nice way to define RM Source and RM Destination to make it clear that they were not limited to just one endpoint or port. The closest I came was to add some text to the definit
Linkion of each that talked about how they were not limited to one endpoint blah blah blah...    But I thought that wouldn't be any better than my original proposal because it would probably make people stop and think too much about what we were trying to say.  So, what I came up with was this:
- remove the "endpoint" in places where we said "RM Source endpoint" and "RM Destination endpoint" - as Jacques suggested

- tweak the "exactly two parties" sentence we talked about during the f2f

- remove the tying of the RM Source/Destination to the WS-Addr headers in the CreateSequence section

- add just *1* sentence expanding the scope of the RM Source and RM destination concept in the RM Model section.  I tried to keep this sentence short so to not over-complicate things but still allow the freedom I was looking for.


I've attached a pdf file of the spec with the change bars on.  You should find 9 changes.  For easy finding they're on line #s: 80, 146, 213, 305, 313, 315, 435, 436, 475,


thanks

-Doug



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