ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] i010 - a proposal
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Tue, 18 Oct 2005 18:18:27 -0600
Jacques,
ok I added "reliable"
to the definitions - I think that does help. As for adding a new
glossary term I agree I'd prefer that to be a new issue.
For reference I've included another
version of the pdf file - hopefully this will be one we can discuss on
Thursday.
thanks!
-Doug
Jacques Durand <JDurand@us.fujitsu.com>
10/18/2005 06:07 PM
|
To
| Doug Davis/Raleigh/IBM@IBMUS,
ws-rx@lists.oasis-open.org
|
cc
|
|
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 definitLinkion
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
issue10.pdf
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]