WS Arch F2F -- 24 Sep 2003

Present: MikeC, Katia, TomC, Martin, Hugo, DaveH_(arrived_late), DougB, Frank, Zulah, DBooth

Regrets:

Chair: MikeC

Scribe: dbooth

Meeting Schedule

Scribe: ugo, yes, hold on...
... Schedule change: Formalization will be this afternoon. Privacy will be Friday morning.
... DaveH and MikeC will be alternating chair coverage.

Planning the WSA endgame: What MUST we do to declare victory?

Scribe: TomC reported that Daniel Austin was working on the project plan, but didn't have anything to show.

MikeC: We need to come to a reasonable milestone.
... Prob not a proposed rec. But maybe Last Call working draft.
... We'd have Nov meeting to get in shape whatever's going to be included.
... Then the Jan F2F could be for ironing wording and consensus.

Martin: Nov meeting would be helpful if it's the same mode as Jan meeting. If we go through page by page in both meetings, that should be good.

MikeC: That modus operandi means that if we can't get consensus on something in two consecutive meetings, then we'll have to remove it from the TOC.

Frank: My concern is our customers. Can we tell our customers "this is the arch, go use it"?

MikeC: What do we need to do from the customers point of view?
... What do we need to say about things that are over the horizon, such as semantic integration?

Frank: We can't do the semantic integration right now. However, our primary task is to clearly elucidate the space where semantic integration goes and what it would look like. Perhaps a model charter for a WG.

Frank: Right. Oracle made an interesting presentation last week in the chor F2F that suggests a way forward for that.
... The image I had in my head was cogs in a gear box. They have different tasks, but need to meet appropriately.

Katia: But what does it entail? A communication language with common semantics, at least.
... I'd propose that we identify at which places in WSDL, Chor, etc. that we need additional constructs or elements to enable this.
... These are the places that may help if these things were included.

TomC: Semantic interop isn't something we can attain easily. We need the broad vision of what has to be done.

Geoff: Deja vu. The way of doing that is not technical. It's a social, business, etc. problem.
... We can point out the need for the evolution of mechanisms for high level interop, but each domain will be different.

Martin: People have been trying this for years. UBL. (Universal BUsiness Language). It doesn't work except in limited cases. EDI only defines about 10 message sets.
... You have to sit down with your partners.

Katia: In the past we didn't have the technology. About semantic interop, we're not talking about imposing a universal language, we're talking about identifying places where we could glue things up.

TomC: I deal with semantic interop daily. If we can't say explicitly how to solve the problem, we should place some constraints about where it may fit. Minimum is to say where it fits into the WS arch -- not conflict with SOAP, WSDL, etc.
... Document needs to say what semantic interop is.

Eric: We need to ack sem web in our doc with placeholders, but not solve it.

Frank: +1 to TomC's comment. We need to lay out the gap in the arch for semantics.
... My concern is that customers already have deep expectations for WS. Unless we tell them we haven't met the hype yet because there is this [semantics] piece we haven't solved yet, we're not being honest.

Ugo: Want to understand how sem interop relates to sem web.
... They may be different problems.
... I'd like to understand how much help we can get from sem web activity.

Katia: I agree with Ugo. THe sem web by itself won't give you interop. It's a substrate for semantic interop. One can define concepts and then programs can reasonable whether they are the same, similar, etc.
... So it will provide some infrastructure for WS. Some of the efforts in DAML-S and OWL-S allow you to describe a composite WS, for example.
... THe WSDL for Amazon is 35 pages. A mess. It is not program understandable. A human would have to read and understand these 35 pages. If you used DAML-S, it's easier for a program to understand, eg, that this is a sequence of atomic processes.
... So that helps program understanding.

Ugo: Suppose you have an app for ordering books from B&N, and then I want to start buying books from Amazon. Would my app be able to figure out the similarity and adapt?

Katia: Suppose B&N requires ISBN, but Amazon requires title and author. Sem web would help you with the relationship between the two.

Ugo: Crucial point would be establishing the equivalence between that information.

Katia: OTOH, we do have a little service at CMU that takes WSDL documents and translates them into DAML-S.

Scribe: ACTION: Katia to send URI of CMU app that takes WSDL documents and translates them into DAML-S

TomC: This is far more than what we could be into our document.
... There are 3rd parties that provide sem bridging. They provide semantics behind the WS. We should bring out in our doc if there's something missing.

Frank: We're getting very detailed. And a technical note on equivalence: It's generally not doable.

Hugo: What do we want to put in our document? I am hearing that we want to recognize that semantics need to be addressed, and we could put in a placeholder for it for future work.
... At the last AC meeting, the TAG noted that there are lots of things they could do, and asked the meeting about what it should do. The meeting opted for describing the web arch now, rather than what it should be.

Scribe: 1. Make a statement that this is a business problem that the real world must work out and can do so with our plumbing.
... 2. Put in a placeholder statement that WSA version 2 will address this.
... 3. Propose new WGs to address semantics. State that we think the following areas should have WGs. E.g., OWL-S, discovery, etc.
... 4. Note potential of tools such as CMU's WSDL --> DAML-S translator. Talk about things that can be done with existing tools.

Geoff: It's saying that there is a tower of babel, and the solution is not just technological, but social and business practices.

TomC: Bare minimum is to say that in WSA these are the things that you need to comply with, but beyond that you'll have to use other means.

Geoff: Option 1 is like complaining about the weather. There isn't anything we can do about it.

Martin: You can either document the current reality, or say what is needed for the future.
... Does our doc do either of these now?
... Can someone reading the doc see how WSDL, SOAP, etc. fit in?

Scribe: (Martin was not specifically addressing semantics.)
... Katia notes that our doc mentions WSDL as an example of a technology for service description.

Martin: It's a choice: Are we describing things today, or what is needed in the future?

Hugo: People wanted something useful today from the TAG. They didn't want to wait 2 years.

Frank: The arch is a framework in which we can position individual specs. We don't need to explain them at all.
... Today's work is covered by SOAP, WSDL, etc.

Zulah: (Meta comment) Maybe we should make breadth first decision about what's needed first.

dbooth: We've identified one more thing that we still need to address in our doc: semantics. I suggest we now look at our list of remaining things, and decide how we wish to address each one.

What to say about Semantics in our doc?

Frank: There are real world aspects, but tools are missing. There are tech tools that businesses can use. Maybe 50% of OMG is devoted to domain-specific activities. But the tools were APIs, and they were baking things in at too low a level.

Geoff: Important to set expectations correctly.
... Also going beyond basics requires continuing domain-specific involvement.

TomC: ONe issue raised on the list was about constraints on the Arch. It's good to say what's needed, but without constraints it's somewhat meaningless.

Zulah: One thing that would help in WS management is an understand of how semantics SHOULD relate to WS, rather than a willy-nilly attempt to decorate everything with semantics.
... People are trying to do this today. Consistency would be nice.

Martin: Still need to describe how SOAP, WSDL, etc. fit together.
... Example: discussion of WS-addressing. Suppose two endpoints for a WS point to different machines. What does that mean?

Katia: Our arch document is a level above that. We point to WSDL and SOAP as potential tech for implementing the arch.

Scribe: 0. Potential criteria for completeness
... a. Primer of primers (overview)
... b. WSA ontology
... c. Recommend new WGs
... d. Vision of future

Zulah: I see a big gap between a and b. An ontology is a conceptual arch.
... I'd like to understand things like: How does locating a WS work?
... How should I think about representations? I think of those as primer stuff, then other things as ontology material.

Martin: We've got WS-Security, UDDI, WSI Basic Profile, etc. We know they'll affect the WS space in the next year or so. I think we need to include those kinds of things in option a (primer of primer / overview).
... Arch stack must reflect technical areas of all these specs. We need a framework sufficient for placing all of the various specs in Roger's proposed list.

DaveH: Always a trade-off between depth of detail and scope of coverage. Everything I've heard here makes sense. But our charter is about to expire. I think we should ask: "What do we need to declare victory?"

MikeC: But this morning, we heard comments saying that we need to look from our customers POV.

DaveH: If we select only the TOC and maybe 1/2 to 2/3 of our current doc, we could get something out.

Scribe: (Discussion of whether having an arch framework sufficient to relate existing specs is doable)

<DaveH> what is minimum for victory...we can elaborate later in notes/papers and revisions

dbooth: How do these high level objectives translate into specific needs for changes or additions to our doc, which is well along the way?

DaveH: I hope we can focus on the TOC from the current draft, and ask: Is there anything we need to add before we close this TOC?

Frank: One of the stakeholder sections tries to address the question of whether the arch framework is sufficient to relate existing specs.
... Someone needs to do the legwork on this.

Scribe: ACTION: Martin to review the document (by the next F2F) against a list of specs from the POV of asking whether the arch framework is sufficient to relate those specs to our arch.

Scribe: ACTION: Zulah to write a section on QOS (expanding Sec 3.6.2.3)
... ACTION: Zulah to recommend TOC structure regarding policy and draft text for missing sections on policies.
... (discussion of where manageability should go; Frank notes it should be in stakeholders section)

Hugo: Something like WS-Policy is broader than what we call policy. Maybe we're not using the same notion of "policy". It's really more like constraints and capabilities, and I'm not sure we're addressing this.
... E.g., A requirement of "I accept only 128 bit encryption" for security. Could also stipulate things like encoding, language, etc.

Scribe: ACTION: Hugo to review our doc and propose how WS constraints and capabilities should be addressed in our doc. Due 17 October.

(TOC Deltas) Semantics

DaveH: We have two sections in the TOC that address semantics. Do we need changes to our TOC regarding semantics?

Katia: If we're talking about gaps, the TOC needs something on the future of WS regarding semantics.

Frank: Three things need to be addressed: 1. What do we mean by semantics? 2. WHere are the pointers to descriptions of semantics? 3. Is there a conceptual framework for higher level interop?

Scribe: ACTION: Frank to review sec 3.5 to propose a new name for it and ensure it covers: 1. What do we mean by semantics? 2. WHere are the pointers to descriptions of semantics? 3. Is there a conceptual framework for higher level interop?

MikeC: Need to say something about the future, because of our charter to scope potential new WGs.

DaveH: Another way to approach the need is to identify gaps without going too far what will fill that gap.

Geoff: If we have a framework for extensibilty we have to mention the future.

MikeC: But people want an exec summary of what's needed next.
... Maybe we should have a summary.

DaveH: I suggest each section in 3 should end with a "future" section identifying gaps.

Zulah: So there's a suggested form for the stakeholder sections: What it's about? (background) What the arch addresses? What it doesn't address? Then gaps.
... The most important goal of the doc is to identify arch gaps.

Scribe: AGREED: Each stakeholder section to conclude with a discussion of the gaps relative to that section.

(TOC Deltas) List of what is remaining to be done

Scribe: Quoting from http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Sep/0016.html item 4:
... [[
... 1. Security framework -- need a complete story
... 2. Discovery - fill out and resolve inconsistencies
... 3. Clearer connections to other ideas and specs
... A) SOA
... B) Making sense of the overlapping specs and proto-standards
... C) Proposals for future W3C work - try to define standards or
... adapt to diversity and rapid change?
... 4. General doc specificity, consistency and readability.
... A) Formalism -- UML? DAML/OWL? These are presumably appendices
... B) Integration of glossary with concepts
... ]]
... 1. Security framework -- ok in TOC
... 2. Discovery -- ok in TOC
... 3. Clearer connections to other ideas and specs
... A) SOA -- ok in TOC
... B) Making sense of the overlapping specs -- (Martin has action to review this)
... C) Proposals for future W3C work -- ok in TOC (because we'll now address at the end of each stakeholder section)
... (discussion of reliable messaging, and what we might say about it)

MikeC: Might identify two kinds of gaps: 1. We don't understand what's needed, and arch work needs to be done; or 2. We understand the arch of what's needed, and there are competing specs in the marketplace.

Scribe: 4. General doc specificity, consistency and readability
... A) Formalism -- (deferred until this afternoon)
... B) Integration of glossary with concepts -- ok in TOC (on impact)

Zulah: Some stakeholder sections are unclear about there purpose. Should we have guidelines for stakeholder sections?
... I anticipate Management to have some normative text.
... Should it be in the stakeholder section?

Scribe: ACTION: MikeC and Katia to draft (prior to next F2F) and propose a summary section for consideration by the WG

Discussion of poll on making a list of specs

Scribe: Poll results: http://www.w3.org/2002/09/wbs/34341/WSList/results
... AGREED: Poll results do not change the previous action item to Martin. No additional actions needed at this point..
... (Discussion about closing the TOC)
... AGREED: WG has concensus that TOC (subject to exceptions noted above) is complete. TOC is closed.
... [Lunch break. Continuing at 1:30 PT]
... Who is on the phone? Ugo? Shishir?

Formalism

<ericn> agenda: presentation of framework discussion
... I.e. what other syntaxes for formalization (in addition to text of course) can get added into the document, such as UML, OWL etc.
... Should the current diagrams (section 2) be rendered in UML?
... Call for UML diagrams in the document
... Frank: There are two UML diagrams that should be added into the document on SOAP and WSDL, hasn't happened yet, should go into Stakholder's viewpoint
... Clarification: diagram function is informative
... Specifically the five model diagrams in section 2 - should they be redone in UML? And if so, who will do it?
... Zulah: Question is whether the diagrams are intended for communicating concepts or are formalism, and if they are formalisms they should be in UML
... DaveH: My understanding of the purpose is to help navigation, not a formalism, the text may be normative but not the diagrams
... DaveH: Record agreement that the role of the diagrams is informational and navigational, and they will continue to exist in their current form
... JeffM: Need to at least add notational reference to explain the conventions in the diagrams
... DavidB: Separate the discussion about the purpose of the diagrams from explaining the notational conventions
... DaveH: Summary -- agreement to stay with the current format of the diagrams and add a section in 2.2 for explaining the convenstion of the diagrams and in section 3 explain the purpose of the diagrams around helping the reader understand
... Martin: Disagree, diagrams should be in UML
... Correction to explanatory note, should be in section 2.2.3
... DavidB: Question is whether we should change the format of the diagrams
... DaveH: Ok, let's split the question, first on whether or not we should change the format of the diagrams and second about adding explanatory text
... Frank: Diagrams do use well known notation, and UML seems more obscure
... Mike: UML is a more obvious choice, it's obscurities are well known and its tediousness well supported by tools, I'd prefer to change to UML unless there's some technical reason not to

<ericn> Martin: There's a lot of stuff in UML but you don't have to use it all, all we're taling about is changing the words has and is to diamonds (etc. in UML)
... DaveH: Afraid to use UML here because it seems like false precision, don't want to give the impression that things could be generated from the diagram
... DavidB: More important for the group to move ahead than take on an additional work item without willing volunteer to do the work
... MikeC: Speaks to the benefits of UML rigor, for example our finding issues with SOAP and WSDL in the process of creating the UML diagrams
... DaveH: Is there a motion to change the format of the diagrams?
... MikeC: Yes, I propose we use UML, Martin seconds.
... 8 opposed, 3 in favor, 2 abstentions
... DaveH: We can move on, motion defeated.
... But of course (as several note) if someone does create useful UML diagrams we should consider adopting them.
... Next item on the agenda: Discussion of Katia's OWL work with respect to potential inclusion in the document as an appendix or other suitable place
... Hugo: Raises issue of ensuring diagrams, text, OWL in synch
... Bijan_Parsia: Offers to help with early and late review of the OWL mapping, happy to help with review
... * thanks to you both
... DaveH: Anticipated that the OWL appendix will meet the needs of those looking for RDF
... ACTION: Tom Carrol to respond to the RDF issue to say that we're doing it in OWL

<ericn> ACTION: Frank directed to add notation information to appropriate section to explain existing diagram conventions (possibly Section 1.4 or other appropriate place)
... ACTION: Eric to author sections on SOAP and WSDL to help improve the explanations of them
... JeffM: Ensure text on SOAP and WSDL reflects ongoing work in the WGs
... Versioning problem of specs and architecture an acknowledged issues
... Next item on agenda is security, Frank and Katia to lead discussion based on what's in the spec, and what's in other specs not currently in the WSA document, whether to include them or not etc.
... DaveH: Goal is to agree table of contents for security is complete
... Hugo: Let's discuss the framework Abbie came up with
... PaudD: Raises specific issue of how the WG will manage impact of change in foundational specs
... After the break, resuming with discussion on security

<hugo> Their policy and our policy are not similar
... They are expressing capabilities and requirements
... Discussions about what the community and W3C should do
... Frank: security needs to be addressed properly by this architecture
... Zulah: where is the so-called security framework in our document?
... Frank: not all there yet

<ericn> Security isn't one thing
... How much of it we need to capture in the architecture is the question

<ericn> Hugo: I brought up Abbie's framework because it's different from what we have in the document and discusses topics such as trust, resolving identities etc. which all seems to be missing from the document
... Hugo: For example I haven't seen message level security anywhere, so I think we need to address the issues the way he did, with our frame work that's how to solve those problems
... DaveH: I'd be included to include a short description in Section 3 to say what security is, combination of encryption, trust, tokens, channels -- not only to send messages but also authenticate, authorize, etc. and identify it as a gap and move on
... Zulah: Can say similar about management, but that doesn't mean there aren't some architectural aspects we can define for the scope we're in, need more than a paragraph and a TBD
... Goeff: WS-I precedent indicates we should not try to go too far

<ericn> Frank: Boils down to using Web services with confidence from the user point of view, we need to answer that question
... Frank: Major problem with Abbie's analysis, positing the existence of a trust agency, which is not realistic
... Martin: They do exist
... Geoff: Problem is the unique clearing house concept
... Might be able to resolve Frank's concern via editing
... DaveH: Nominate Abbie's text for inclusion in Section 2, with diagram instead of identifying it as a gap in Section 3
... Hugo: Including text in Section 3 is a minimum, but would be good to include it in Section 2

Scribe: Current "policy" section (2.3.4 "Policy Model") is: (a) narrower than discussing WS constraints and capabilities in general; and (b) slanted toward security.
... WS constraints and capabilities are related to semantics.
... WS-Policy is about expressing capabilities of a WS and the contraints on its use.
... There is a stakeholder's viewpoint on security (3.6 Web services security).

<ericn> Relationship between semantics and security assertions may need to be clarified.
... DaveH: Change 2.3.4 to be Security, introducing a small number of concepts from Section 3.6 and from Abbie's text, put them into the model, then move the rest of Abbie's text (edited) into Section 3.6
... DaveH: Clarify that the root of the diagram should be security rather than policy
... Zulah objects
... Frank: The policy info relates to quality of service, management, application level role as well - making it more general than any one topic such as security
... DaveH: proposes items to conclude upon
... DaveH: Section 2.3 is narrower that it was, on policy specifically
... DaveH: Security model needs to be created, who can do it?
... DaveH: Clarification - security is one of the things that will be included within policy
... DavidB: Are we assuming we need an additional diagram?
... Yes
... DaveH: Motion to Add a 2.x section labeled "Security model" carried unanimously
... DaveH: Now let's consider taking policy out of 3.6 and making it its own section, and Section 3 peers with policy and security
... Frank: Says the section numbers are wrong
... DaveH: Sections 3.15.2 and 3.15.3 on SOAP and WSDL - if we modify the wording in these sections do we address Ugo's concern around the security impolications?
... ACTION: Ugo to propose text for Sections 3.15.2 and 3.15.3 on security implicatgions for SOAP and WSDL
... DaveH: Does this effectively wrap up what needs to be done for security, characterized by saying that no further impact to table of contents?
... Agreed
... ACTION: Katia and Frank to add 2.x "Security Model" with Hugo's help (including interface with W3C staff expertise as necessary)
... Adjourned
... -ericn

WS Arch F2F
24 Sep 2003

Attendees

Contents

Meeting Schedule

Planning the WSA endgame: What MUST we do to declare victory?

What to say about Semantics in our doc?

(TOC Deltas) Semantics

(TOC Deltas) List of what is remaining to be done

Discussion of poll on making a list of specs

Formalism

Editors' meeting

Summary of Action Items

WS Arch F2F 24 Sep 2003

Attendees

Contents

Meeting Schedule

Planning the WSA endgame: What MUST we do to declare victory?

What to say about Semantics in our doc?

(TOC Deltas) Semantics

(TOC Deltas) List of what is remaining to be done

Discussion of poll on making a list of specs

Formalism

Editors' meeting

Summary of Action Items

WS Arch F2F
24 Sep 2003