WSA Minutes - Wednesdy July 30, 2003


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
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”?
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

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.

Minutes formatted by David Booth's perl script: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
$Date: 2003/10/01 15:59:07 $