See also: IRC log
Present:Abbie Barbir, Dave Orchard, David Booth, Doug Bunting, Frank McCabe, Gerald Edgar, Hao He, Hugo Haas, Katia Sycara, Mario Jeckle, Martin Chapman, Mike Mahan,Paul Denning, Roger Cutler, Shishir Garg, Ugo Corda
Regrets: Chris Ferris, Daniel Austin, Dave Hollander, Sinisa Zimek, Suresh Damodaran, Zulah Eckert
Scribe: Frank McCabe
<dbooth> ACTION: MikeC to ask Geoff if he
took additional minutes off line on 4-Sep-2003 conf call
... Agenda: http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Sep/0016.html
<dbooth> Action items: http://www.w3.org/2002/ws/arch/3/09/ActionItems.htm
Scribe: Katia has looked at WS-Policy, etc. needs to be looked at
... Glossary updated with sync/asyn language
Katia: Presentation about semantics at the F2F?
Mike: What is the appropriate formalism for doing the architecture
... What is needed to declare victory
DaveO: I have no problem with sets of proprietary documents being listed in the WSA
Martin: the purpose of the WSA is to provide a framework
... Cannot predict evolution of proprietary documents
DaveO: So what?
scribe: Is DaveO volunteering to produce this list?
Mike: what recommendations should WSA make to the W3C?
dougb: Am hesitant in turning the WSA into a FAQ
DaveO: suggests a straw poll to see if group wants to construct such a list
Scribe: ACTION: Mike, DaveB, DaveH to draft a straw poll
<dbooth> ACTION: MikeC, DBooth, Hugo to draft a straw poll asking whether people want a list of proprietary specs in our WSA document
DaveB: Which specs should be listed
DaveO: This could indeed be contentious, e.g., Message reliability
Martin: Compare and contrast - takes a lot of time.
Mike: is this required for victory?
Roger: if everyone contributes their lists, then this may be easier
MikeM: The purpose is to identify missing functionality
Mike: editing: consistency in document, e.g. glossary and concepts, e.g. usage scenarios
<dbooth> Frank: Can we discuss the uniform interface topic at
the F2F? There are some constraints that we haven't addressed.
... ... Such as: What are the appropriate abstractions for interop between WSs?
... .... Will the way we're doing it lead to large scale interop?
... Frank: For example, if you have two Web services, what would it take to make one service out of the two?
ugo: no clear way of combining document standards
... just being able to send a document doesn't mean you can understand it
<dbooth> Frank: YOu can't solve all the semantic problems at
once. But you can peel off a couple of layers of the onion that will give a
lot of leverage.
... ... Without that, we'll end up with CORBA for the Internet. That's the risk. We still won't have global WSs.
... MikeC: Suggest discussing by email.
... ACTION: Frank to start email discussion on what constraints are needed for truly global WSs
Scribe: ACTION: to propose some better layering on message semantics to promote interoperabilty at a global level
<dbooth> Roger: We also need to do something about the usage scenarios.
martin: Usage scenarios is a means to an end, not nec. part of the final victory parade
Roger: useage scenarios is an identified part of the output
... not organized properly
DavidB: agrees somewhat with martin
DavidO: Should not be required for victory
... Should be pragmatic about available time, resources
Scribe: ACTION: put review of Usage Scenarios doc be Chairs to put on the F2F agenda
Hao: what about reliability
Mike: remind people to respond to message reliability
Hao: text about relationship with REST
... What to do about REST
Mike: has tried to pull SOA messages together
Scribe: a response to Mike's message
MikeM: I like mike's version, lets move on
Hao: SOA is higher-level than the Web architecture itself
... extensibility is fundamental
DavidO: the myth of loose coupling
DaveO: not on the same page about architecture, esp. relative to constraints
<rcutler> Myth of Loose Coupling: http://lists.w3.org/Archives/Public/www-ws-arch/2003Jan/0115.html
DaveO: what are the fundamental constraints of the WSA
Scribe: e.g. extensibility
<mchampion> frank: generally agrees with daveo, many WS "ilities" are emergent properties
Hao: good practice shades into constraints
DaveO: You apply constraints to yield properties
<dbooth> DaveO's message on the Myth of Loose Coupling: http://lists.w3.org/Archives/Public/www-ws-arch/2003Jan/0115.html
<mchampion> Daveo: for example, interoperability is a property that emerges from constraints and limiting choices, not a property itself
DaveO: how is extensibility different for WS c.f. the Web
Mike: Focus on getting words in the document
<Hao> I already proposed a definition of "loose coupling" in the glossary
Scribe: ACTION: to the editors: use service requestors and providers
Mike: its in the glossary
DavidB: Can I use the word the service?
Mike: we need to be consistent in our terms
... we use requestor as a synonym for consumer/client
... we use provider as a synonym for server
Scribe: Scribe thinks that a service provider provides a service to a service requestor
<dbooth> dbooth: So the editors should avoid the terms "client" and "consumer", perferring instead "requester". We should also avoid the term "server".
Scribe: ACTION MikeM should check that the Liberty Alliance's terminology is consistent with the WSA
<dbooth> ACTION: MikeM to check that the Liberty Alliance's terminology is consistent with the WSA
<dbooth> WS-CHOR WG)
Mike: in a world in which there are different, competitive specs,
e.g. in message reliability, what should the WSA do
... Should we allow the overlap, or should we pick a winner?
Martin: there is an issue, how to specify the choices
... where is correlation covered?
Mike: Reliable messaging is required. There are multiple RM specs out there.
Martin: We need a binding framwork, let the market choose the winner
Mike: binding framework should be part of the WSA