[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim Minutes of 7/13 teleconf meeting
The Prelim minutes are attached. Please provide corrections before Friday evening I just initiated a 7 day KAVI ballot to make Editor's draft 1.05 into CD 1.05. Tom Rutt -- ---------------------------------------------------- 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
|
Prelim Minutes WSRM TC Conference Call – The meeting of the WSRM TC will take place by teleconference Pete noted it is not necessary to address late comments. We may choose to do so. 1
Draft
Agenda:
Draft Agenda to WSRM TC Conference Call 2 Roll Call 3 Minutes Discussion 3.1 Appointment of Minute Taker 3.2 Approval of previous meeting minutes – 4 Action Item Status Review 5 Discussions of unresolved comments 6 Scheduled Vote for CD (only if all comments are resolved) 7 Scheduled Votes for further progression (only if CD is voted yes) 7.1 Vote on whether changes from CD .992 are substantive 7.2 Vote to Submit to OASIS for member vote (subject to no vote on 7.1)) 7.3 Vote for second 30 day public review (subject to yes vote on 7.1) 8 Discussion of document progression and future meeting schedule 2
Roll
Call
Attendance:
Meeting is quorate. 1
Minutes
Discussion
1.1 Appointment of Minute TakerTom Rutt will take minutes. Minutes will serve to record issue resolutions. 1.2 Approval of previous meeting minutesThe minutes of the July 06 teleconf are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7696/MinutesWSRMTC070604.htm Bob F moved, alan seconded. No opposition , minutes approved 2 Status of Action Items2.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.
2.2 Action 060104-5 (Jacques) PendingAction: Jacques, will propose further edits, on the FAQ for composability. Still open, low priority 2.3 Action 070604-1 (Anish and Doug B) PendingAction on Doug and Anish to come up with a proposal before the end of the week to resolve the schema for references. They are making progress. 2.4 Action 070604-2 (Tom Rutt) ClosedTom Rutt will add new Public Comment issue on Faults without Ack requested and close with agreed resolution from 7/6 meeting minutes. Pubic comments issues list, with all issues as of July 06 meeting resolved, and incorporated into Editor’s draft 1.05 was posted at: 2.5 Action 070604-3 (Iwasa) ClosedIwasa will publish a new editors draft 1.05 with the agreed changes above. Draft 1.05 was posted as: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7598/WS-Reliability-2004-07-07.pdf 3
Discussion
of Issues and editorial Comments
The following issues list includes items which
have been resolved as of the output of the The
following additional issues and comments were circulated to the list for
discussion. These need to be resolved
before we can vote on a next CD. 3.1 Comment on the ref Schema· Minor technical issue (or two) in the
reference.xsd schema · Re: [wsrm] Minor technical issue (or two) in
the reference.xsd schema Next week we will discuss. 3.2 Comments from Mark Peel· Non-exhaustive proofreading pass on 1.05 spec The above comments are editorial in nature. Please post to the list if there is any disagreement. · 1.05 inconsistency In Table 22 (line 1081), InvalidMessageParameters, we find "4. when groupExpiryTime
decreases for a subsequent messages. in an ordered group" (sic) But in lines 1205-1207, we find "The protocol allows change (up or down)
of @groupExpiryTime, as long as it is never less than max(ExpiryTime) of messages received so far for the group." I conjecture lines 1205-1207 are correct, in
which case we should strike item 4 in Table 22 and renumber item 5
following to 4. Mark
Peel Tom Rutt: I agree with this proposal. Agree
in principle with Mark’s
proposal. Post to the list if there is
any disagreement. 3.3 Comments from Chris Ferris· comments on ws-r 1.05
Discussions of these comments at the meeting, by number, are recorded in the following table:
Bob
F: what is the status of these comments. Doug:
Chris was kind enough to make comments to us, and I would rather thank him for
that rather than worry about how these comments arise. Tom:
many of these comments are easy to resolve.
Members should post proposed changes to the list. Tom:
Members should post any proposed text changes resulting from these comments to
the list before next Monday. · Re: [wsrm] comments on ws-r 1.05
36
thru 41 No
time to discuss these comments, in detail, however some are easy to resolve. 27 38 39 40 41 Tom:
Members should post any proposed text changes resulting from these comments to
the list before next Monday. · Re: [wsrm] comments on ws-r 1.05
comments on the ws-r schema at: http://www.oasis-open.org/committees/download.php/7109/ws-reliability-1.1.xsd The schema defines two base types, HeaderBaseType and ExtensibleType, which allow for attribute and element wildcards. For simplicity, I'll simply list the ExtensibleType definition: <xsd:complexType name="ExtensibleType"> <xsd:sequence> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax"/> </xsd:complexType> And then these types are derived by extension, as in the case of RequestType: <xsd:complexType name="RequestType"> <xsd:complexContent> <xsd:extension base="wsrm:HeaderBaseType"> <xsd:sequence> <xsd:element name="MessageId" type="wsrm:MessageIdType"/> <xsd:element name="ExpiryTime" type="xsd:dateTime"/> <xsd:element name="ReplyPattern" type="wsrm:ReplyPatternType"/> <xsd:element name="AckRequested" type="wsrm:EmptyType" minOccurs="0"/> <xsd:element name="DuplicateElimination" type="wsrm:EmptyType" minOccurs="0"/> <xsd:element name="MessageOrder" type="wsrm:EmptyType" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> In the spec, the graphic in figure 6 suggests that the element wildcard content follows the wsrm:MessageOrder element when in fact, it actually precedes the MessageId element according to XML Schema which only supports extension via appending. The note in section 2.2.1.3 of XML Schema Part 1 reads: NOTE: This specification allows only appending, and not other kinds of extensions. This decision simplifies application processing required to cast instances from derived to base type. Future versions may allow more kinds of extension, requiring more complex transformations to effect casting. Either the spec or the schema should be modified to correct this inconsistency. Also, I am puzzled as to why the formal prose and tabular definitions of the elements for this spec do not identify those elements which are extensible via element and/or attributes. Cheers, Christopher Ferris Ter: I believe this merits Discussion, and are easier to fix. Doug: is the ordering identical between the figures, tables and schema. The text do not describe what elements are extensible and when we do show it the any is on the wrong side. Iwasa: should we assign someone to define proposed resolutions for Chris issues. Doug: everyone make proposals to these issues, and discuss the ones that did not get discussed by email. Chris is on the list, and he may respond if we ask for clarification. Jeff: We should have this be done on the list. Doug: rather than assigning people to issues, those that see resolutions we can post them to the list. Anyone who wishes to propose resolutions, including no change required, to chris comments post them to the list. We will discuss it next week. Tom:
Members should post any proposed text changes resulting from these comments to
the list before next Monday. 3.4 Comments from Doug Bunting· drb comments on 1.05 Title: drb comments on 1.05 Number Location Priority Problem Suggestion 1 line 3 major editorial A minor version change implies minor differences between those versions. The submitted WS-Reliability 1.0 specification and our current 1.05 draft are very different documents. We should not be implying they are as closely aligned as this naming implies. Change version number to 2.0 or rename the specification. I prefer the former. Jeff: I agree 1.1 is fine here. Iwasa: this was discussed previously, and we agreed to call ws-reliability 1.1. Jeff: I disagree with Doug: Tom: it is not backwards compatible. Jeff: we should call it OASIS WS-reliability 1.1. Doug: I move to change the version number to 2.0. Tony Graham seconded. Majority Opposed (see roll call vote in Attendance list table). Motion did not pass. 2 line 10 editorial Is Iwasa really the only editor? Add at least Sunil and Jacques, who contributed mucho editing time. Let Jacques, Sunil and Iwasa Discuss this together. 3 line 17 editorial A committee draft is a static indication of the TC's view at a particular time. Once the document is anything other than a working draft, this line is incorrect and inappropriate. Delete this line. 4 lines 25-26 editorial Have we created a blank errata sheet or do we have a plan to do so? If not, these lines should say something about "when available". Change "The errata page for this specification is at" to "If necessary, the errata page for this version of the specification will be located at" and confirm this location is under TC control. 5 line 67 minor technical WS-Reliability is a number of SOAP modules, not just one. It also seems very odd to describe a protocol with specific message exchanges added to the application interaction (producer / consumer interface in our terms) simply in terms of the syntax added. Finally, as Chris also mentioned in his initial comment 5, this reliance on SOAP 1.2 terminology implies a SOAP 1.1 -only implemenatation is not conformant. Remove "is a SOAP Module (as defined by [SOAP 1.2]), which" Joe C: how about SOAP based capability Jeff: “is a SOAP based specification, which” General agreement on Jeff’s proposal as the proper resolution. 6 lines 78, 81 editorial "Under this aspect" adds nothing to either of these points. Remove these phrases. 7 lines 105-106 editorial "On the sending side, like on the receiving side" adds nothing. Delete this phrase. 8 lines 117-119 editorial? Bullet about "application level synchronous messaging" has never made sense. The bizarre semi-clarification in bullet conflicts with the value duplicate elimination might add if the producer (in our terms) wants to repeat messages until it gets the response it expects. Delete this bullet. 9 Table 2 minor technical Our specification is supposedly useful for both SOAP 1.2 and 1.1. If we need a namespace prefix only for SOAP 1.1, something is very wrong in our specification. Add some SOAP 1.2 examples and define namespace prefix for that namespace here. Doug: We do not define a prefix for Soap 1.1. We never use soap 1.2 in the examples. Doug: one soap 1.2 example would fix this. 10 Section 1.3 editorial This "conventions" section seems the appropriate place to describe what in the document is normative. Normative is not mentioned until page 41 at the moment! Are examples and notes normative, for example? Are the examples without "(Normative)" in the subject non-normative? Is the associated schema normative (see lines 600-602)? Describe what in the document is normative. This is a question of writing it down in the spec. Members should proposed text to clarify what is normative in the spec. If people do not disagree, we will accept these editorial comments next week. 4 Scheduled Vote for CDDoug: Does anyone feel we need a committee draft around this time. Jeff M moved to progress Draft 1.05 to CD status, Bob F seconded. Vote (see roll call vote in attendance list table) 13 yes out of 20 voting members = 65% < 2/3 of voting members Vote for initiation of KAVI vote, Alan moved, bob seconded. No opposition Kavi vote
will be initiated tonight. Draft 1.05
and the schemas will be put out for 7 day Kavi vote,
to close 5 Scheduled Votes for further progression (only if CD is voted yes)Do not have CD, agreed to wait for further progression until after resolving final editorial comments. 6 Discussion of Document Progression and future meeting schedule.Agreed to continue with weekly two hour meetings. Key: Next step whether the next CD should be for member vote or for public review. Tom: Tom everyone put there final comments on Draft 1.05 before next week. Bob: I would rather all comments to change from the Draft 1.05 before next week. Tom: Proposed text changes, by next Monday evening, to discuss on next Tuesday call. July 20 meeting target to resolve all text changes. July 22 or 23 new editor’s draft for review. July 27: have meeting only if there are objections to the comments. July 29, stable document available for final review. Aug 3 try for CD ballot. If not quorate we initiate Kavi Ballot after Aug 3 meeting. If we are quorate we could start the 7 day Kavi Ballot on Aug 4 morning. Aug 10, Possible skip that meeting. Alan: Need one meeting cycle for editorial review, prior to another CD. Bob F: For information: There is an article on CNET stating that Tom Glover, from IBM, stated that there has been a decision to profile reliability in WS-I. It might make sense to review that and to make some comments to that. Jeff M: the article does not state a decision has been made. Bob F: there is a requirements document circulating in the WS-I Requirements group. Alan moved to adjourn, Doug B seconded. No opposition. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]