[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 5133Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003
|
Preliminary Minutes WSRM TC Conference
Call – The meeting of the WSRM TC took place by teleconference
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
Attendance:
Meeting is quorate. 3
Minutes
Discussion
3.1 Appointment of Minute TakerTom Rutt will take minutes. Minutes will serve to record issue resolutions. 3.2 Approval of previous meeting minutesThe minutes of the June 22 teleconf are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7489/MinutesWSRMTC062204.htm 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 Items4.1 Action 052503-1 (Tom Rutt) pendingTom took an action item to complete the status column of pre public review issues list, with correct URLs.
4.2 Action 060104-5 (Jacques) PendingAction: Jacques, will propose further edits, on the FAQ for composability. Still open 4.3 Action 062204-1 (Jacques) ClosedAction: 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
· Summary of WS-Reliability 1.01* issues
discussed over past week · Groups - COntribution-JD-WS-Reliability-2004-06-21.pdf
uploaded · Re: [wsrm] Groups -
COntribution-JD-WS-Reliability-2004-06-21.pdfuploaded Jacques,
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). -Sunil · comments on Jacques Update on mep mappings
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 request". 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 elsewhere. 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
· RE: [wsrm] clarification on Respond primitive · Re: [wsrm] Discussion on Duplicate
elimination issue from 6/14 minutes 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 PC26Sunil 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 already 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? -Sunil http://www.oasis-open.org/archives/wsrm/200406/msg00110.html 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: http://www.oasis-open.org/archives/wsrm/200406/msg00115.html Sunil: > <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 SchemaNo time to discuss, defer to next meeting: · Minor technical issue (or two) in the
reference.xsd schema · Re: [wsrm] Minor technical issue (or two) in
the reference.xsd schema 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. Thoughts? > 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 QuestionsTom posted the following: · Approved
FAQ set for WSRM TC Doug B moves to adjourn, Mark Peel seconded. No
objection, meeting adjourned at | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]