Present: Bryan Thompson, Chris Ferris, Daniel Austin, David Booth, Doug Bunting, Eric Newcomer, Frank McCabe, Hao He, Hugo Haas, Katia Sycara, Martin Chapman, Paul Denning, Roger Cutler, Shishir Garg, Tom Carroll, Zulah Eckert
Regrets: Daniel Austin, Steven Lind / Mark Jones (AT&T), Yin-leng Husband
Chair: Mike Champion
Scribe: David Booth, Shishir Garg
7/30 WS-Arch notes AM session MC: morning is stakeholder’s perspective – we’ve got a lot to do here. MC: after the break we will have a discussion on “what is a web service”? MC: there are a cpl other things for after lunch •Some discussion of flight times and how long we can meet* MC: after lunch, we should talk about (after the Ur-trout discussion) publication plans MC: other topics – input to the TAG, XMLP future work items MC: introductory parts of the document need some discussion MC: main points are publication, Ur-trout in the afternoon MC: Begins discussion of stakeholders view section of the document MC: -interlude- off topic MC: discussion of section 1 – Mike wrote it FM: the stakeholders view need to be discussed FM: what of this material do we want to cover? KS: what stakeholders do we want to represent? KS: there are other view that need to be added, potentially FM: stakeholders are not necessarily viewpoints, but a human that acts as an implementer or user – there are many of these? MC: from various points of view, such as EJB, we can consider the architecture important FM: this is the section of the document that is used for this purpose FM: I wrote some of these, trying to give a model for what I though it should be. FM: I did security, but there has been some pushback MC: are we representing users or viewpoints CF: perspectives? KS: * quotes an example* shows difference between users and perspectives DA: req xref neds to be done MC: outlines different possibilities, aspects, perspectives, etc. CF: these are features FM: it’s an ilitiy MC: that’s what we originally called it KS: stakeholders are gathered in this section, but it might be easier to do orgainzie it according to aspects RM: I thin the latter is best, it’s no consistent at this point, but it’s really a discussion of features MC: queue up! -white board- CF: I don’t understand why we are separating these things, they are all discussing the same thing MC: the original idea was (from Arizona f2f) theis is supposed to be theorems or macro level explanation, rather than the detail view. DB: it almost sounds like its not supposed to be readable CF: it’s the opposite MC: there a lots of examples and references, concepts and relationships MC: CD is suggesting that we need prose to explain the basic concepts. MC: next sections would be more rigourous RC: I really agree that MC is right, there is a lot of repeated material, why not move it into the conceptual part, and make it explicit? KS: again I p[ropose that we separate the at we clearly differentiate this section KS: I think we can leave the structure the same, and when it is better organized, we can point back to previous text or sections KS: it can be done either way, but needs to be done clearly. KS: we shouldn’t try to decompose it now FM: I think the mapping to requirements is different FM: we need to sho how the fundamental goals of the arch. Are met at a conceptual level FM: the themes of the are need explication FM: I would vote for two sections MC: I think we need an introductory section FM: not concerned with textual order FM: I think we should spend time on what we’ve done, what are the sections and themes? MC: do we think “themes” is correct verbiage? FM: we tried several alternatives DB: requirements xref should be in a separate document MC: I always find this boring DB: I don’t think our readers care much; this is for us, not for the users DB: our audience has expanded KS: what do we mean by requirements? DB: contents of documents RM: our audience hasn’t expanded, it’s not written down that way MC: we can’t change the charter, but the requirements at will MC: but I agree with Doug, the user doesn’t care MC: there’s another issue, have we had a requirements creep? Martin: figure out what sections we need, figure out the contents, and not getin sequencing issues Hao: from the end user’s POV, they will have to create reference architecture RM: There are 5 documents that we created, that we’ve said we’ll maintain it RM: I thought the glossary was to be part of the document Hugo: we don’t have a plan MC: for sanity, if the glossary is included, it should be an appendix Hugo: schema was done as one piece CF: getting the glossary to spec will require consensus across to many groups Hugo: we’ll always have that problem ZE: We keep having the conformance document discussion, until we create logical models we can’t even discuss this ZE: continues rant Hao: I agree MC: what’s the diff between conceptual model and ref. Arch. Martin: reference architectures don’t really exist ZE: that’s ludicrous TC: in 1.1, -quote- in the next para, it says we are going to deal with interoperability, but we don’t do this. We don’t impose any restrictions, so what’s the point? Let’s change the name of the document to something else. FM: you’re misquoting it FM: we’re supposed to be talking about stakeholders, and conformance is useless anyway FM: conceptual conformance is the same as technical conformance DA: but those results don’t matter DA: it doesn’t improve interoperability DB: it’s a ref model, not architecture TC: the underlying theme is that some of us are expecting something more concrete MC: we don’t want to reference specific specs or versions KS: clarification: what happens to the doc when it goes to req? RG: interrupts with points about agenda KS: the next point, are we going to have the reqs xref KS: it took us ½ year to create them KS: to me these are the ones that need to be xref’d KS: and they should inform the arch docs KS: we need to do this mapping effort ZE: the conceptual model is not very valuable ZE: I don’t believe that it meets the requirements ZE: it’s a waste of time to discuss how we met the reqs for the conceptual model ZE: I can’t be party to any such fraud ZE:I think we need the logical models, or nobody can implement anything DB: there are some points of conformance, but not in our document! DB: it’s clear that we don’t have any normative statements FM: ZE made an interesting comment; I think it will be true for all that the doc will not meet any stakeholders requirements, not from any point of view FM: I think we could revisit our goals, but we won’t meet the user’s requirements FM: how much are we actually going to be doing for the users? FM: I would say that we either meet the reqs or tell people how they can do so FM: I don’t think that we should care about the requirements FM: let’s talk about the writing about the stakeholder’s section and who will write it TC: looking at the document, it’s hard to say who would find it valuable TC: it would help to have specific roles that describe the POV RM: looking at the doc, I don’t have a copy of the reqs but I think it says that the architecture should support various scenarios, and supporting them is part of the objective for the stakeholders RM: if there are serious gaps between the arch. And the published usage scenarios PD: we can’t have any user scenarios for the document itself ZE: If I go back to the users, they would have to create their own logical models ZE: this will be lots of work, and lots of research, we have no reference architecture just a conceptual one FM: can we define a logical model? ZE: ACTION: post logical model definition to mailing list KS: should we add guidelines for users of the document? CF: the whole notion of conformance seems ridiculous, but we should include words about how this document should be used. CF: we are providing guidelines for how users can go along with our ideas CF: it’s about the glue between parts CF: but we can’t talk about conformance, people will use it if it’s useful MC: do we want to ratchet up the formality of this? MC: I don’t think so ZE: We’ve been talking about this since day one ZE: we need to agree on what we should have, and go for it, whether it’s Zackman or 4+1 ZE: and then look at what we’ve got and how it fits KS: are there two action items here? ZE: we need this to determine what conformance means KS: the job is too big to do anything formal MC: the reader should come away with some value added to their lives, efforts made easier MC: there are multiple suggestions: use the reqs xref, describe it as high level features, we can’t use the scenarios without an editor and an update, Other suggestions? FM: there are two things, a section on what this arch is, and another is to look at our goals list and see if it’s a reasonable starting point. FM: the intro/primer should be different from stakeholder’s views FM: the usage scenarios are extremely out of date, more like the SOAP ones RM: the usage scenario isn’t entirely useless MC: there are two logical fixes for the scenarios doc, get somebody to fix it, or harvest it for our other purposes Hugo: about the usage scenarios, it’s a huge document, and no small task to edit it, but the travel agent scenario might still be useful, we refer to it a lot PD: one thought I had was that the stakeholders, whomever they are, might be matched to user scenarios RM: the EDI example has real-world input CF: so does the travel example KS: the user scenarios can’t be mapped onto our conceptual architecture MC: does it seem useful to have the user scenarios as a standalone doc or just incorporate it MC: that would be more manageable RM: we could create a new document from the ashes of the old, perhaps smaller Hugo: the current doc is unmaintainable Hugo: perhaps a smaller doc would be more manageable MC: docs have to have editors, any volunteers? MC: Hao, are you volunteering? Hao: no MC: what’s the minimum required to declare victory? RM: Dave O worked on it, would he volunteer? MC: he left it because nobody seemed to care or take it seriously RM: do we have any management scenarios? ZE: there are lots of scenarios, but we need to do the logical view first. Hugo: I can contribute, but not lead BREAK: Rough consensus that stakeholders chapter needs reorganized, cleave more tightly to end users POV, also features, address the features. We also need a 50K view section, also that we need to usage scenarios document rebooted. After Break: MC: next thing is the Ur-trout discussion, and Dave Booth’s poll, but Dave is still in WSDL, but will try to come back before lunch MC: were there any discussions during break that were useful? RM: the old document includes many harvested scenarios, but it’s incoherent, some are very detailed, others are not. We should take section 3 and simplify it, make it representative of the scenarios RM: this will take a lot of clean up. RM: there will be lots of broken links RM then we take section 3 and connect it with section 2, including references a nd backlinkgs elsewhere in the document RM: this will produce a usable document MC: why do the work on sec. 2? Why not just remove it and start fresh? RM: we get to reuse existing content Hugo: we could live w/o a lot of the detail, but we need still lots of references RM: we need this to xref this with the arch doc MC: that would help illustrate the gaps in what we’ve done RM: the document is currently indigestible MC: that sounds good, what’s the timeline, a month? Hao: I’ll help MC: anything else? KS: we looked at the requirements doc and found that some of the CSFs and reqs are very detailed and don’t match our document, esp. around level of detail. FM: many of them are difficult to see how to meet MC: we need to remove all the detailed stuff from the doc so we can meet our reqs FM: reliable, stable over time is meaningless FM: we should say robust MC: we should modify the ones that are measurable, and remove them ACTION: Chairs to make this an action item for a future telcon KS: we can talk about how the xref will work MC: a smaller problem is the conformance problem – we all have diff ideas what this means MC: my take on this is minimalist, too many diverse backgrounds and motivations, we can’t set the bar too high MC: on the other hand, I think there is some clarity around issues now MC: the semantic web is an example MC: someday in the future, we may be able to make inferences around the doc, in a future version, but we can’t MC: the discovery talk by Dave Booth was illustrative MC: that’s my idea f conformance MC: should we be more normative in the document? ZE: I’d like to have the Ur-trout before leaving MC: let’s go ahead with it then ZE: some of us would like more normative tech. Statement FM: I know what a web service is even if you don’t ? MC: I expected that we would be able to view the questions of the poll DB: it’s about 15 messages MC: what are the pssible definitions of a web service? What were the poll results? DB: he sent the results out Hugo will write the results on the board REF: poll on Ur-trout, see mailing list MC: the issue was, “do we try to define what a WS is for the whole community, or try to define it locally, in terms of the scope of our WG?” MC: we did a poll PD: the results were an even split, Dave’s suggestion was to define it locally, and acknowledge that others will have differing opinions RM: I think we’ll be more successful if we define it globally DA: mutually inconsistent definitions will not produce interoperability ZE: WSDM is likely to come up with a diff definition ZE: goes into details about WSDM group’s thinking DBooth: I based the wording on the poll results ZE: You could create a definition that isn’t weasel worded RM: lots of pplhave done this, it doesn’t work ZE: what if you added some variables and let everybody else fill in the blanks ZE: attempts do tackle the trout, gets nowhere Hugo: this def. Should go into the document to replace the current one Hugo: after all this time, we still don’t agree RM: we are talking about section 1.5 right? ZE: the level of detail is strange to me, some parts are uneven DBooth: remember the context Hugo: can we have a straw poll on this def. CF: I’m uncomfortable with the weasel wording, let’s tighten it up DBooth: specifics? CF: provides examples that he doesn’t like RM: you don’t care about compromise? CF: no CF: identifies parts of the definition that he doesn’t like CF: WSDL should be included as the description language, and other details CF: we need to focus on what the other WGs are working on DBooth: the poll results were about evenly split, between Chris’s position and against it ZE: we should be more prescriptive, in terms of technologies and other specs Hao: we would strongly object to any prescriptive statements regarding technologies KS: I agree with Hao MC: I was going to suggest that we should have something pretty weaselly in the document, but follow it up by saysing that the scope for this document is much more narrow, but that we would say strongly urge people to use specific technologies like WSDL. Hugo: isn’t that pretty close to the first part now? Hugo: the second part goes into more detail MC: not sure, we might need the extra words FM: it picks on the message model and ignores everything else, but there is a point that this is a W3C group and it needs to reflect W3C concerns and results FM: its concerned with the message model, which isn’t fair. FM: it’s concerned with only the bottom level of the stack, there is more to a WS CF: that’s fair, but we do need to include those aspects TC: perhaps we should include some other different levels of description other than the message model, try to find a definition that covers a broad scope TC: I don’t think this def. Precludes extension, but it isn’t very flexible TC: we need to include specific technologies though RM: so what should we do about it? TC: I agree with the direct approach, but we need to provide the user with some context. Currently it’s very top down. CF: so you want some additional text to provide context to make our WS’s distinct from other ones KS: Will it be a stake in the ground or weasely? TC: All I want is a broad definition above the existing definition, and then define a W3C Web service definition, that will provide specifications of the realization. CF: You are free to do XML over HTTP. The first sentence caveats that. CF: for this group we should focus on existing, current W3C technologies, or else its irrelevant. We need to scope it to the rest of the activities. We don’t want to preclude other technology, they can be added later, on top of a def. That we all agree on. DBooth: How are we going to move this WG forward? We’ve talked this to death, with many arguments on both sides, but no new ones. Dbooth: SO how are we to move forward? DBooth: options are a) continue arguing over it b)more straw polls to try to narrow the field c) formal vote on the issue d) adopt multiple definitions and say that the WG could not agree. MC: do you think that we have been held back by this? DA: fifth option is to not try to define it all PD: we could put in an Ed. Note saying that we don’t agree (on #4) DBooth: I want to move ahead, that’s my real issue ZE: I agree with Sun & Oracle, we need to be compatible with the other W3C technologies for consistency. RM: why not accept then? ZE: the result would be useless DBooth: those two things aren’t necessarily connected DB: the definition has been normatively referenced by others, who preface it by noting that it is useless DB: I agree with Chris & Tom, we need to define the basic parts of the system DB: i.e. specific encodings, etc. and then go into something prescreiptive Hugo: we have 6 months to get something usable done. The sections on policy and others are useful. I’m worried that we might exclude some things by being too specific. Hugo: constraining ourselves is the only way to get moving ahead Hugo: about defining a broader kindo f web service, this will only lead to a new rathole Hao: the document should be useful to solve business problems. DBooth: Chris, do you feel that SOAP must be part of the definition? CF Yes DBooth: what about WSDL? CF: Yes DA: could we just say “w3c technologies”? All: NOOOOO! MC: many WS would be excluded CF: yes, that’s okay CF: ppl will look at this document for a clue, and this is one clue we can provide. All of these other approaches are completely valid, but are not what we are doing in this working group. The group was formed initially to solve a problem, and we are getting distracted. This is important for my company CF: this is one of the most important parts of the document, the only part quoted by others. Hao: look at what ppl are doing with the technology CF: all the tools, including ours, suck. But we do talk to our customers about it. DB: we don’t want to document what has already been done, but to be forward looking. KS: we say this definition works for us, locally, but not for others MC: I heard some suggestions: use the tech references as variables, users need the document and definition for guidance or simply regard everything that doesn’t fit our definition as non-WS oriented. An alternative definition: A WS is a s/w system designed to support interoperable machine-to-machine interaction over a network. It has interfaces described in a machine processed format, specifically WSDL, Other systems interact with the WS in a manner prescribed by this description, using SOAP-based messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. Taking a vote: adopting the above in section 1.5 W3c: y Texaco y Thompson N Grainger abstain France telecom: abstain Mitre: Y Software AG y Sun Y Carnegie Mellon: Y Oracle: Y IBM: Y 8 Y, 1 N, 2 abstain decision is carried by the yes votes ACTION: editors to add this to the document ACTION: to publish document amended with new WS def, plus editor’s changes Group agrees.