Working Group home page · Meeting records
See agenda posted by the Chair.
-------------------------------------------------------------------- Agenda 1. Assign scribe. We will be working down the list at [0] [0] http://www.w3.org/2002/ws/arch/2/04/scribes-list.html Scribe: Paul Denning -------------------------------------------------------------------- 2. Approval of minutes [1] from last 2 week's' telcon [1] http://www.w3.org/2002/ws/arch/2/10/minutes17October.html (Time=0344 ET) Minutes approved. No objections. -------------------------------------------------------------------- 3. Review of Action items. ACTION: DaveO: Write text on use of URIs within DIME. [PENDING] [1] [CLOSED/OBE] ACTION: DanielA: will provide some information on meta-models. [PENDING] [2] still pending ACTION: DaveO: provide some pointers to Roy Fieldings Architectural Metamodels [CLOSED] ACTION: Hugo to sort the MTF's situation out [4] Zula has meeting minutes. Work in progress. Heather does not have a complete set. [PENDING] ACTION: MarkJ to send wording to Hugo about attachment feature implementation [5] [CLOSED] ACTION: Hugo to finalize and send response to the XMLPWG [6] [CLOSED] ACTION: Doug to send new wording re swizzling [7] [CLOSED] ACTION: Hugo to add some text asking to AF motivation [8] [CLOSED] ACTION: DaveO, to write something about documenting best practice (fuzzy action item wording, but David will know what it's about) [9] [PENDING] MC Should WSAWG review WS-I profile? CF Recommends reading it. DO. Formal WSAWG response to WS-I should be an option. E.g., look at terms like metadata vs service description. Different definitions would be bad. Both WSAWG and WS-I doing work in this area (defining terms). Don't wait to send in comments. --------------------------------------------------------------------- 5. David Orchard suggests [4] that it would be a good thing to ask the OASIS ws-security tc if they could provide wsdl definitions as part of their v1 output. [4] http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0197.html Hal OASIS Liaison DO. Potential issues. WSDL definitions WS-Security elements in messages See WS-QOP list Question of timing BEA feels WSDL should be in scope of OASIS WS-Security TC. Should WSAWG ask OASIS WSS TC to make WSDL in scope? Hal concurs with DO summary. Added that WSDL should not be gating items for publications of WSS spec. WSDL should not be a dependency Many views on scope. Little or no operational experience. Separate TC for just this issue is a possibility. DO. Narrow scope is easy to defend. BEA concerns to address interoperability. WSDl would help ensure interop. Can interop be assured without WSDL? E.g., how to specify password info. If runtime things in spec makes it hard to describe in WSDL at development time, may want to change WSS spec to better address WSDL usage. BEA feels it is generally good to have WSDL in addition to a spec. (Hal?) Need more specifics. How long would you be willing to delay WSS spec in order to get WSDL? SAML auth token? What authorities do you trust? Other questions. What is minimum needed in a WSS WSDL? More than just well-formed XML. 1.0 min should have non-normative description of WSDL, prefer normative. Use extensibility features already in WSDL, not changes to WSDL spec. DO. Want elements (e.g., username, password, X.509 cert). Particulars of business arrangements, values of attributes should be beyond scope. Hal does not feel WSAWG views would be objectional to WSS TC, but can't guarantee they would take action either. Does WSAWG believe WSDL is good for interop? MC. Any contrary views? Hal, please indicate tradeoffs and use cases. Everyone is in favor of "WSDL", need to say more than that. DO. Avoid meddling in WSS TC. [ACTION] DO, revise proposal based on Hal's feedback. Try to give types of things that WSAWG MC. Do nothing (no WSDL) is not acceptable or preferable. (Speaking for Roger) August 2002 slides of real-world web services. (Doesn't need WSS?) Hugo. Can be discussed at WSCG meeting next week. DO. How and when does WSAWG need to engage WSCG when interacting with non-W3C groups like OASIS. (0415) Hal. Only approx 12 of 60+ members of WSS TC have participated in QOP discussions. MC. recap. get concensus within WSAWG on DO's revised proposal. DO. Ask WSCG if it is improper to send such a message to WSSTC. --------------------------------------------------------------------- Reviewing latest editors draft of WSA document [2] and glossary [3] Please look over the latest editors copy of these documents and make comments. We will discuss what needs to be done and decided upon to go to a public working draft by the end of the month. [2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html [3] http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/glossary/wsa-glossary.html? rev=1.12&content-type=text/html (0417) 2 documents. CF. cc wsa-comments list. MC. Hugo. Expect some people to be unhappy with some definitions in glossary. We'll need to agree that its good enough to publish without full concensus on all definintions. CF. Thanks to Heather. ??. WSDL Primer contains some general web services discussion. Should we draw from it to add to WSA glossary? F2F agreed to postpone a WSA primer until later. (Scribe note: I don't think he was talking about a WSA primer, rather using info from the WSDL primer to populate the WSA glossary). Need to meet external committments, especially, Architecture document. BEA believes reliability is very important and should be one of the next topics addressed. MC. Everyone should think about 1-3 things that are most important to them, bring to F2F. WSAWG will need to decide on priorities for near term work. Choreography will be mute by next WSAWG F2F (AC will have decided by then). DA. WG members have to take responsibility for their own issues until they make it into document. Next week telecon will be decision by WG. Should send comments before end of business next Tuesday. [ACTION]. CF to send message to admin list. ========================================================================== 4. Choreography (0430) There has been considerable discussion about choreography on the mailing list this week, but no signs of consensus on what the scope of a choreography WG would be. We need to focus on: 1- A working definition of "choreography" and related terms. 2 - Requirements for the choreography WG. 3 - How to fit choreography into our document to help the AC understand it. 4 - Realities: Is there a subset of the choreography space that is ripe for standardization (e.g., by a one-year focused effort)? Could a common choreography interface definition language be standardized and let multiple execution languages contend? Or should we be preparing the AC for a multi-year effort to standardize something on the scope of BPEL4WS? ----------- (0445) Triangle diagram discussion. Does it have a place for choreography? Need to show relationships between services. Nothing explicit. DO. current diagrams do not show multiples of web services. editor call Hugo action to diagram a group of choreographed web services. FM. 2 aspects. 1. how to do choreography, 2. where does choreography fit in overall web service architecture? Finite state machine diagram. What problems should be addressed at different levels of abstraction. DA. We have good start. Add recursiveness to address multiple web services. FM. Need to address what problems are solved by which diagram. Audience now is AC. Need AC to understand why new WG is needed in context of web services. DO. Choreography instances talking to instances. triangle diagram okay if just trying to capture that a web service is also a client of other web services. Need something more to address view of flows. Can we harvest from the 100's of emails on this topic? Roger Cutler started thread asking why are we doing this anyway. Who should harvest? Lots on what it is, little on why. Need more rationale for doing more work on Choreography. [ACTION] FM will take a stab at text to explain where choreography fits in and motivation for it. He will draw from list. Need volunteers. General call for WG to take another look at archive and reflect on specific requirements that a Choreography spec would solve. CF. Email ettiquette, Change subject line when discussion fragments. DA. Encourage more time before sending to list. MC. Should suggest specific changes for specific document. DO. Use travel agent scenario for now rather than introduce lots of vertical industry scenarios. Work at requirement level. DA. Counterproductive to be negative and contrary to WG concensus. Support the will of the group. Some mail from outside the WG, hard to control. CF. Focus on moving the document forward. (0452) MC. Anyone disagree with focus on travel agent? FM. Roger's use cases are not covered by travel agent. DO. Need architecture to support many use cases, but use travel agent to frame debate and talk specifics less abstractly. Add uses cases judiciously. MJ. No trouble with a use case elaborated, but illustrate as many edge cases without overcomplicating it. Also value in shallow usage scenarios. Tradeoff. DA. Restaurant example, argued to the use case rather than the concepts that the use case was trying to address. DO. Likes MJ suggestion. Go deep with travel agent, plus shallow for others to get edge cases, lots of interations. MC. Hugo action from editor meeting, will be picked up by DO. FM. During choreography, focus on stakeholders rather than message exchange patterns. Need different players views. MC. Take it to email. DA. Use "role" perspective. MC. Hopes we can make AC happy (narrow scope) but also address W3C members and broader web service community who may expect broader scope. AC meeting is on 18 Nov. Draft to W3C in about a week. Editor draft a few days before meeting. DO. Worry about this deliverable. Doug. Reduce scope to meet deadline. MC. Next 2 weeks is a good time to spend more time away from day job and help WSAWG get ready for this AC meeting. DO. Will attend AC meeting, so will be available to help with presentation if needed. MC. Focus on documents, and where we want to be by AC meeting. Adjourn. (0506)
http://www.w3.org/2002/10/24-ws-arch-irc#T21-03-49-1