OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[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 5133


Title: 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:

1) review 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 Call

Attendance: 

 

First Name

Last Name

Role

Company

vote on Motion

Pete

Wenzel

Voting Member

SeeBeyond *

n

Anish

Karmarkar

Voting Member

Oracle Corporation*

y

Paul

Knight

Voting Member

Nortel Networks Limited*

n

Robert

Freund

Voting Member

Hitachi, Ltd.*

y

Eisaku

Nishiyama

Voting Member

Hitachi, Ltd.*

y

Nobuyuki

Yamamoto

Voting Member

Hitachi, Ltd.*

y

Tom

Rutt

TC Chair

Fujitsu Limited*

y

 

Meeting was quorate.

 

3          Minutes Discussion

 

Tom Rutt Volunteered to take minutes.

 

3.1       Approval of previous meeting minutes

 

The 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 Items

4.1       Action 012505-1 (Tom Rutt) Pending

OASIS 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) Closed

Action: 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

Mail from Jamie Clark, OASIS staff:

120229

use of "wsrm" in docs. oasis-open.org namespace

James Bryce Clark

03 Nov 2005 18:30:05

     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 activites

The 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 Response

On 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 TC

Jamie 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 Business

Bob moves to adjourn, second by anish.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]