See also: IRC log
Present:
Regrets:
Chair: SV_MEETING_CHAIR
Scribe: UNKNOWN
<zulah> Martin: message relia bility is the set of delivery
properties that relates to the delivery confidence that you want.
... DaveH: are we comfortable with accepting the proposal that someone goes
off and creates a proposal based on this. Is there a volunteer
... ACTION: Frank and Hao, refactor the definition of reliable messaging
based on "delivery-policy" and the explainantion
... daveh: any thoughts to give the actionees?
... Martin: transaction should be in the service section
... Frank: Confident that they can make another go at this
... ACTION: Frank, change model to reflect delivery policy, add 2.? section
for delivery policy, change stakeholder on reliable messaging.
... Next item - usage scenario document
<dbooth> Hao's refactored doc: http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/scenarios/ws-arch-scenarios2.html
<zulah> Hao: restructured document to put 2-3 major use
casesa t the beginning. Added cross references within the doc. Would like
more scenarios (e.g., rest)
... Frank: is there a real difference between the static and dynamic
discovery case
... Hugo: dynamic discovery has alot of magic involved whereas the static one
is much more concrete.
... Hugo: last time we agreed to discard the dynamic one - or to put some
notes but keep the static one as the main case
... Hugo: EDI is still a completely separate use case, would like to in the
travel agent use case, include the EDI use case (or what is was showing) -
that's the static travel agent.
... Abbie: is there a structure to how the scenarios are done?
... Abbie: In WS-I there were three basic scenarios (1-way exchange, 2-way
excahnge, intermediary) then you can add the static vs. dynamic
variations.
<DaveH> good morning...ready to get started
<hugo> Agenda: http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Sep/0052.html
<DaveH> Katia scribes off line
... discussion of management lead by Zulah
... information space for management ws:
... 1) identity
... 2) state
... 3) configuration
... 4) metrics/performance
... 5) topology/relationships
... events -- operations -- attributes -- relations
... ws identity and ws state
... context: asset, security, policy, QoS - all need to be
described/commented/or something
<dbooth> ACTION: dbooth to ensure that management is mentioned in the intro
<ugo> I have to go. Don't bother using the microphone if I was the only one on the line