WS Architecture WG call
17 Jul 2003

See also: IRC log

Attendees

Contents

• Topics
• Summary of Action Items

<hugo> Agenda: http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Jul/0023.html

Scribe: minutes approved 7/3 & 7/10
... ai review

<dbooth> Meeting: WS Architecture

Scribe: Chair AI - done
... David/Hugo AI - pending
... DaveO AI - Sharshir did this - Maybe Done
... DaveO AI is pending
... Igor AI - Igor not here, and pending
... DavidB AI - poll results next week
... Shishir AI -- Done
... MikeC AI - Done
... EricN AI - pending
... MarkJ AI - DOne
... Hugo AI - done
... Chair AI - agenda for later today

<dbooth> WS Poll: http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Jul/0021.html

Scribe: Chair AI-2 - reminder
... Daniel to take AI to publish ???

dbooth: clarifies straw poll

<mchampion> ACTION: Daniel will publish requirements doc before the F2F

Scribe: dbooth - there are questions on the questions .... metaquestions
... document progress

<Roger> DBooth aggrees that this is the meaning of having the "definition" questions separate from the "scope" questions if you are one of the people that thinks they SHOULD be coupled:

Scribe: 4b - plan for publishing next public draft

<Roger> If the WG decides to have separate sections in the doc about the defintion of the term WS and the scope of the WG, THEN

Scribe: 4a approval for new document structure

<Roger> What do you think should be in section 1 (def) and what do you think should be in section 2 (scope).

Scribe: the state of the doc's xml is much better now than prev f2f
... contents & structure - we can publish anytime we want

hugo: heartbeat is beginning of august
... can merge today comments into doc tomorrow

Scribe: MikeC - would it make more sense to publish after f2f
... Roger - the current working doc is very different than the last published doc
... Roger - so it makes sense to publish it now
... Frank - but if we publish now - do we want to give ammoo to the tech writers

hugo: compromise solution - make the most current editors copy by Monday the published version

MikeC: gives us a chance to vet the doc at the f2f

Scribe: MikeC - now is the time to thumb up/down on the current doc structure
... I still haven't had time to review

Frank: current struct - no spagetti diagram, 5 main models - message, service, policy, management,
... stuff in 2.1 - is now in the meta-model: concepts, relationships, features & models

MikeC: the group doesn't like the term meta-model

Roger: it is a description of the organization of the document

<bryan> *I* like metamodel ;)

Frank: it is like the OMG terms

Scribe: Roger - wants something simpiler

dbooth: How to read the architecture

Frank: caving....
... real issue - is this a better way of doing the concepts and relationships

Martin: This is a better org - in UML this is analagous to packaging

Frank: recognizes packaging - but is not the exact right concept
... Package doesn't capture the coherence of the internal structures

Martin: UML package can capture whatever the designer intends

MikeC: I am happpy (with the new org)

Scribe: Chris is the meeting host not Heather

<dbooth> ChrisF, try http://cgi.w3.org/Register/selectUser.pl?_w3c_special=listRegistrants&_w3c_meetingName=WSAWG_WSDWG_200307

Chris: new content looks more machine processible than mortal grokable

dbooth: the intro is suppose to be helpful here

Chris: it needs to be more readable

Frank: 1) Stakeholders viewpoints is a way to read the arch to see if it meets their needs and this is very readable

Scribe: Frank 2) agrees it would be useful to now abstract upwards for a higher view

MikeC: a primer?

Martin: no, there shouldn't be a primer for an arch doc

Chris: the arch doc should be the primer for the architecture!

Chris: I like the content, more than the presentation

<bryan> I like the content and the issues that it surfaced. I am waiting to see where it leads, e.g., in terms of narrative.

Frank: maybe another person (Chris) could help

MikeC: group should all chime in to expose the hard to read areas
... xml.com article - the doc is written for spec writers not tech weenies who publish

dbooth: but we have to keep it in mind that they will read and publically read

Roger: the stakeholders viewpoint is readable but hard to find

MikeC: content is fleshing out - now wordsmithing

Geoff: While you might want to make the doc more readable - you doen't want to lose any formalism the doc contains

Frank: we haven't spent time on the stakeholders section

MikeC: Give myself AI to put that on next week's agenda

Frank: there is a stakeholders section on securit

MikeM: what happened to the uml diagrams

<MChapman> think the uml diagrams should be put in an appendix

MikeC: EricN was to merge the lower and higher level diagrams
... editors think that uml details are wrong for this arch doc

Martin: useful to put in a appendix - since they don't exist anywhere

DaveO: Whether we complete coverage to WSDL/SOAP?
... For the portions of models we don't need to include
... what concepts in SOAP are not arch important?
... alot of what is in SOAP seems arch relevant

Frank: we have successfully extracted the relevant material
... we don't need to repeat what is in SOAP
... Detail like how to do bindings to excessive detail

DaveO: strongly wants to put in appendix - if not earlier

Frank: if these are so useful - why didn't the XMLP and WSD groups do it

MikeC: AI to Frank to include diagrams
... MikeM AI to send to editors list versions of these diagrams

Scribe: Frank/MikeC: using editorial perogative to appropriately place
... Intermediaries....

Hugo: the concepts for sender/receiver/inter are close to the SOAP notion of these
... interpretation of the SOAP spec relative to message targeting by intermediaries

MikeC: bigger issue - are intermediaries underappreciated or not very useful?

DaveO: can't comprehend that intermediaries are not very important

Frank: the issue of intermediaries as poor man choreography - then this is bad
... if intermediaries are used for security - then that is OK

<bryan> I don't see intermediares as poor-mans choreography - but I do see a role as security.

MarkJ: Intermediaries have very different roles -

Hugo: we didn't champion message header

Frank: how is an intermediary not a choreography - excluding the encrpytion issue

Martin: the important concept is transparency

dbooth: at what level do we describe the arch

Frank: in the security model - there is an issue of enforcement
... one needs to be able to point to that guard
... so for security and qos - this referencing is important

MikeC: message header owner is needed
... are these 1st class concepts

MarkJ: the XMLP group underspecified the range of archs which can implemented
... including how these makes sense in relation to chor

MikeC: Assign myself to this task

Scribe: Frank; our usage of intermediary could be very diff than what the XMLP group has

Frank: we could call some possibilities as chor
... and other possibilities as part of the security model

<bryan> can frank float some use cases for intermediaries in choreography? or other aspects of intemediaries that WSA might address (beyond security?)

MarkJ: important for us to describe the major roles - there was no SOAP tutorial

<yinleng> There is also some discussion on intermediary in the current email thread on "Recipient 2.2.26 & Sender 2.2.27".

Scribe: MikeM will co-own this

Martin: factor that wsdl omitts discussing this

DaveO: the relationship between inter and message path (use of role attr)
... it would be fine if we can refine these types of intermediaries in more detail
... perhaps wsdl is incomplete in this regard

<bryan> I have to leave, sorry.

DaeO: 2 types 1) sometime routing boxes 2) sometimes performs message transforms

DaveO: we don't have a way to describe this in wsdl - maybe ws-policy targets this

MikeC: times up - people should discuss security issues on ML

Martin: I sent chor text - should be incorporated

MikeC: will AI myself to get this to editors (chor stuff)

Scribe: ciao
... quit

Summary of Action Items