[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: prelim minutes of 11/29 meeting
Prelim minutes are attached. Send corrections to entire list before monday. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Full Agenda for WSRM TC Conference Call –June 14, 2005
Preliminary Minutes WSRM TC Conference
Call –Nov 29, 2005 The meeting of the WSRM TC will take place by teleconference Time Tuesday, 29 November 2005, 05:30pm to 06:30pm ET 1
Draft Agenda:
2) Roll Call 3) Minutes approval 4) Action Items 5) Discussion of WSRX using WS-RM as Product name 6) Discussion of potential TC future activities 8) New Business 2 Roll CallAttendance:
Meeting was quorate. 3
Minutes Discussion
Tom Rutt
Volunteered to take minutes. 3.1 Approval of previous meeting minutesThe minutes of the 10/04 teleconference meeting are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/15420/MinuteswsrmTC110105.htm Bob F Moved to approve the 11/01
minutes, Paul Knight seconded. No opposition minutes 11/01 minutes approved 4 Status of Action Items4.1 Action 012505-1 (Tom Rutt) PendingOASIS Staff has posted the errata cd as: http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-v1.1-errata-cd1.0.pdf However, on the posted standard the errata index is referenced as as: http://www.oasis-open.org/committees/wsrm/documents/errata/1.1/index.html. The errata Index still does not yet exist. The action item will stay open until the errata index page is posted. 4.1 Action 110105-1 (Tom Rutt) ClosedAction: Tom will find out from Jamie what a TC does when it wants to go into maintenance only mode. Jamie stated that there is not “mothball” status for TCs, however a TC can have two meetings a year, if it wishes to stay active in a limited capacity (such as resolution of defect reports). 5
Discussion of WS-RX TC use of WS-RM as Product
name
Recently another OASIS committee, the WS-RX TC, suggested that they use the
partial namespace: [docs.oasis-open.org/wsrm/...] for final
versions of documents. The WS-RX TC is
producing work tentatively
entitled "WS Reliable Messaging", to which the character string "wsrm" was intended to point.
I informed them that the foregoing namespace was reserved for your TC, and that
in our document handling at OASIS, the first token space immediately
after the domain generally is populated from a controlled vocabulary
of the official TC short names. So, for
example, your OASIS standard
is located at:
[docs.oasis-open.org/wsrm/ws-reliability/v1.1/...] ' where
"wsrm" is your TC name token, and "ws-reliability" is the product (spec)
name token.
Some members of the WS-RX TC indicated a desire to use the following possible
alternative approach: [docs.oasis-open.org/ws-rx/wsrm/....] where
"wsrm" would indicate a product name, not a
TC. As you may recall, at this
time, documents are uploaded to the [docs.oasis-open.org] space only by
OASIS staff action. So staff approval
of the correct URI is a practical
precondition to any upload. I informed
the WS-RX TC that, if we received
requests from them to upload to a URI of that kind, OASIS staff would
inquire whether your TC (as user of the "wsrm"
token) had any objection
to it being used in a different context.
Objections from your TC would not necessarily be determinative, but would be a
factor about which we'd want be aware, before acting. I see that you
discussed but did not adopt a TC position on this issue at your recent TC
meeting. We would appreciate being
advised of the views of such TC members as
wish to express an opinion, formally or informally.
Thanks and regards
JBC ~
James Bryce Clark ~
Director, Standards Development, OASIS ~
jamie.clark@oasis-open.org Newer email from Jamie:
This note is a reminder that I asked on 3 November [1] whether members
of your committee have any views about the use of the token "wsrm" as part of a product or spec identifier in URIs for another TC's work, so
long as the token for the TC itself is accurate. OASIS staff have
received some useful comments. FYI, any
other comments should be made by today (Tuesday 29 Nov), as we plan to close
the issue based on input already received.
Regards JBC ~
James Bryce Clark ~
Director, Standards Development, OASIS ~
jamie.clark@oasis-open.org [1] http://lists.oasis-open.org/archives/wsrm/200511/msg00003.html Bob F: the TC could respond that we don’t care (frankly scarlet we don’t give a damn). Anish: I am not sure that our tc can make another tc to anything. But if I am asked a question, is it confusing to have two namespaces with the same token, but in different positions, I would have to say it is confusing. Since these two TCs are working in the same area, the use of a common token across TCs working in the same area is confusing. Not having a common token is less confusing. They could use ws-rs/ws-reliableMessaging as their token. Discussion ensued on the confusion. Tom: I agree with Anish that if they used the full name ws-reliableMessaging, just as we use ws-reliability, it would be less confusing. Bob F: but does it matter. Anish: having no use of common tokens in namespaces is less confusing. Bob F: whose problem is this? Jeff: it is our problem because other stuff gets confused with our stuff. Bob: should we object to the name ws-reliable messaging being used by another TC at all. Tom: having wsrm in different positions of name space will screw up google searches. Bob: from search point of view, we could take position that the tokens and names ought to be unique. This would stop them using reliable and messaging in the same phrase. Tom: do we have a committee position. Bob F: I could support a don’t care committee position. I could also support a full “google confusion” position. Pete: I could support that the ws-rx committee use the full name ws-reliable messaging in their product name. Bob F: the google argument means they should take reliable messaging out of their name. Anish: two issues: what name space should be, and what name of product should be. The google argument states the namespace and product names should be distinct. Bob: Is the argument to prevent confusion. Is so, who is the community we are trying to not confuse? The long url for namepaces is less of a problem than the search engine user. Bob: history is what it is. Pete: if you google reliable messaging the first hit is wsrm TC. Tom: Is Pete’s proposal something the committee can support. Bob: wsrm in google gets our tc. I do not see google confustion in wsrm. If wsrm is an issue, it is not to search engine user. Pete: those oasis urls are not used yet, they are just proposed. Anish: I see Bob’s point of view, but is it feasible. Bob: either we do not have a position, or we have a rational regarding confusion in the industry. The token use in URLs is less of a confusion than the entire google search aspect. Anish: I move that we take the strong principal that ther product name should not be ws-reliable messaging but should be something else. Seconded by Bob F. Pete: while I believe it would be fun to watch, I do not think we should go that far. Bob F: amend to add rationale Based on the rationale that users may get incorrect results using using commonly used search engines. Anish Seconded. No opposition to amendment, amendment passes. Amended motion for vote.: “The WS reliable messaging TC puts forward for consideration by OASIS staff the strong principal that product names of the WS-RX tc should not be “WS- Reliable messaging”, but should be something else, based on the rationale that users do not get incorrect results using common search engines.” Vote on amended Motion, 5 yes, 2 no)) Amended motion passes. (Other members can send their own comments to Jamie today. 6 Discussion of Potential Future TC activitesThe working list of potential enhancements to WS-Reliability was posted after the last f2f as: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/12436/wsReliabityFutureFeatures.htm 6.1 Reliable Request ResponseOn 9/19/2003, a paper was posted to the wsrm mailing list, edited by Jacques http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200309/msg00053.html After review, the TC mail list can be used to comment in this paper, as to its continued relevance to TC future activities. Bob: the next meeting should have on the agenda whether to proceed with working on this feature or not. 6.2 Mothballing a TCJamie Clark told Tom Rutt that there is no “mothball” status for TCs, however a TC can have two meetings a year, if it wishes to stay active in a limited capacity (such as resolution of defect reports). Pete: the TC process stated their must be one meeting per 6 month period. Jeff: there is no official maintenance mode. Which would be asynchronous. Agreed to decide on the next meeting at the January meeting. Decide whether we resolve the one dangling issue, or put the tc into maintenance mode. 7 New BusinessBob moves to adjourn, second by anish. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]