[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: email@example.com; firstname.lastname@example.org 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
The meeting of the WSRM TC took place by teleconference
<![if !supportLists]>1 <![endif]>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
<![if !supportLists]>2 <![endif]>Roll Call
Meeting is quorate.
<![if !supportLists]>3 <![endif]>Minutes Discussion
<![if !supportLists]>3.1 <![endif]>Appointment of Minute Taker
Tom Rutt will take minutes.
Minutes will serve to record issue resolutions.
<![if !supportLists]>3.2 <![endif]>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.
<![if !supportLists]>4 <![endif]>Status of Action Items
<![if !supportLists]>4.1 <![endif]>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.
<![if !supportLists]>4.2 <![endif]>Action 060104-5 (Jacques) Pending
Action: Jacques, will propose further edits, on the FAQ for composability.
<![if !supportLists]>4.3 <![endif]>Action 062204-1 (Jacques) Closed
Action: Jacques will propose text to resolve Binding model issue.
Jacques provided text in:
<![if !supportLists]>5 <![endif]>Discussion of Issues and editorial Comments
The following issues list includes items which need further discussion:
<![if !supportLists]>5.1 <![endif]>PC24
· Summary of WS-Reliability 1.01* issues
discussed over past week
· Groups - COntribution-JD-WS-Reliability-2004-06-21.pdf
· Re: [wsrm] Groups -
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
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:
Summary of Comments on COntribution-JD-WS-Reliability-2004-06-21.Pdf
From Tom Rutt
line 82 : Response should be Respond
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.
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.
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,"
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
Sequence number: 1
Line 364: must -> MUST
Sequence number: 2
LIne 375: must -> MUST
lines 494-499: this note is obscure: All we need is the first sentence.
Lines 528 thru 531: Again this paragraph is obscure, Only the first
sentence is needed.
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.
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.
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.
<![if !supportLists]>5.2 <![endif]>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
>>>> 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
>>>> Service Access Protocol TC" 
>>>> (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
>>>> 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  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.
<![if !supportLists]>5.3 <![endif]>PC26
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
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.
> <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
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.
<![if !supportLists]>5.4 <![endif]>Comment on the ref Schema
No time to discuss, defer to next meeting:
· Minor technical issue (or two) in the
· Re: [wsrm] Minor technical issue (or two) in
the reference.xsd schema
Doug Bunting wrote:
> The most recent copy of this schema 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:any namespace="##other" processContents="lax"/>
> <xsd:attribute name="reference-scheme" type="xsd:anyURI" use="optional"/>
> should instead be
> <xsd:complexType name="ServiceRefType" mixed="true">
> 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">
> <xsd:simpleType name="BareURIType">
> <xsd:restriction base="xsd:anyURI" />
> 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.
<![if !supportLists]>6 <![endif]>Discussion of Document Progression.
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.
<![if !supportLists]>7 <![endif]>Frequently Asked Questions
Tom posted the following:
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]