See also: IRC log
Present: MikeC, Katia, TomC, Martin, Hugo, DaveH_(arrived_late), DougB, Frank, Zulah, DBooth
<ugo> Could somebody activate the phone connection?
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.
Scribe: TomC reported that Daniel Austin was working on the project plan, but didn't have anything to show.
MikeC: What do we need to do to declare victory?
Katia: By when do we need to ask for rechartering?
Hugo: End of Dec is ok.
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.
MikeC: Like the status of chor at the beginning of this 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.
Frank: I'm looking for the equivalent of the resource model.
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.
dbooth: What do we need to put into our document?
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.
Geoff: We will be criticized if we don't do that.
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.
MikeC: Options for what to do around Semantic Interop:
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.
Frank: Option 1 is the tower of babel.
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?
MikeC: Both is one answer.
Zulah: Do we understand what we have and don't have?
MikeC: We need to identify the big chunks that are missing.
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.
Martin: But there's nothing that says how they work together.
Frank: But we are doing that.
Zulah: (Meta comment) Maybe we should make breadth first decision about what's needed first.
dbooth: The "chunks that are missing" is a moving target.
MikeC: But we need to momentarily stabilize the target.
TomC: We need to focus on the fundamental pieces.
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.
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?
MikeC: Do we wait for that kind of thing or say that's for a future group?
Katia: Our arch document is a level above that. We point to WSDL and SOAP as potential tech for implementing the arch.
<hugo> Break; reconvening at 10.55am
Scribe: [continuing after break]
MikeC: Objectives of this discussion:
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
... 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.
MikeC: other potential criteria:
Scribe: e. Conformance
... f. Reference architecture
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?
MikeC: We're trying to define criteria for success.
DougB: How will people want us to change this doc?
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
... 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.
Zulah: Need to add to TOC: In Sec 22.214.171.124, QOS needs its own section.
Scribe: ACTION: Zulah to write a section on QOS (expanding Sec
... 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)
dbooth: Would WS-Policy type stuff fit in what Zulah is discussing?
Frank: There's a section on policies.
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.
<DaveH> semantics: sections 1.5.4 and 3.5
DaveH: We have two sections in the TOC that address semantics. Do we need changes to our TOC regarding semantics?
Frank: Sec 3.5 needs rewriting.
<DaveH> also 126.96.36.199 Service semantics
Katia: If we're talking about gaps, the TOC needs something on the future of WS regarding semantics.
<DaveH> also 1.5.5 Humans, Agents and 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?
DaveH: Seems to me sec 3.5 basically covers it.
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?
Hugo: I propose we go over the list from http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Sep/0016.html item 4 about what we need to do to declare victory.
MikeC: Should we include a section on the future of WS?
DaveH: No. Should be a separate doc if we do it.
MikeC: Need to say something about the future, because of our charter to scope potential new WGs.
Katia: Also would address the requirement for extensibility.
MikeC: Its a big topic, but it's in our charter.
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.
Katia: Proposing only that "future" section is gap analysis.
DaveH: Most of the gaps are identified in the stakeholders section.
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.
Scribe: Quoting from http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Sep/0016.html
... 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)
DaveH: It could just scope the gap.
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.
DaveH: Some are scoped, some are unscoped.
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?
Frank: Anything normative should be in the concepts section.
DaveH: (Notes that we'll be discussing Management later in the F2F.)
Katia: Should we have a "Conclusions" or "Summary" section?
DaveH: This is an arch ref, not a narrative or white paper.
MikeC: I disagree.
Scribe: ACTION: MikeC and Katia to draft (prior to next F2F) and propose a summary section for consideration by the WG
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?
<ugo> I am here. I was on mute.
<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
<ugo> need to sign off for about an hour - back around 3:30
<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
... Is that you Ugo?
<ericn> Discussion on WS-Policy and policy in general with respect to WSA
<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
<DaveH> do we have an abbie framework URL?
<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
... 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
<hugo> Abbie's proposed framework I was talking about: http://lists.w3.org/Archives/Public/www-ws-arch/2003Apr/0255.html
<geoff_a> Just to ref the WS-I paras: http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.htm#security
<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?
... 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?
... ACTION: Katia and Frank to add 2.x "Security Model" with Hugo's help (including interface with W3C staff expertise as necessary)