Web Services Architecture WG F2F -- Tuesday
27 Jan 2004

See also: IRC log


Present: MikeC, Bijan, Hao, Katia, Frank, Roger, Hugo, DavidB

Chair: MikeC

Scribe: hugo


Scribe: Yesterday's minutes: http://www.w3.org/2004/01/26-ws-arch-minutes.html
... Action items: http://www.w3.org/2004/01/26-ws-arch-minutes.html#ActionSummary

Review of yesterday's action items

Scribe: DONE: David to add a section at the beginning of the document to explain the relationship with other documents
... he added a place holder
... DROPPED: David to remove quotes in the documents
... we've been doing it as we go
... DROPPED: Editors will strive to remove apologies, e.g. "some may disagree, but ..."
... we've been doing it as we go

<Scribe> ACTION: Frank to update models diagram [IN_PROGRESS]

<Scribe> ACTION: Mike to bring up the issue of location of address [PENDING]
... Discussing http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html?rev=1.110&content-type=text/html;%20charset=iso-8859-1 Capability

Frank: I think that we should link it with service role

Hugo: Feature here is a SOAP feature

Katia: we may want to define this as a set

Frank: how would that be described?

Hugo: as a WSDL extension, or linked from WSDL, e.g.

Katia: it should have a name

Hugo: I think that this should be changed to feature

Katia: I don't want to lose the concept of functionality

Frank: we need both

Katia: I don't want to use feature, I want to use capability
... in order to use functional type specific things

Hugo: a proposal: keep capability, and say that it's about SOAP features and functionality

Scribe: People agree

David: note that it could be both supported and requested

Scribe: ACTION: David, Katia and Hugo to finish working on capability during break Goal State

Katia: a goal state is the end result

Frank: you may already be in the goal state

Katia: I would like to say that it's the state of the world

Frank: I'd still like to talk about service and resource Intermediary

Katia: I don't want to say modify

Hugo: in which case it doesn't differentiate it with a normal Web service

David: it's en route to another WS

Frank: routing is not a service-model concept

Hugo: it should be named service intermediary

Frank: the essence of a service intermediary is that it modify messages

Hao: I don't understand "equivalent"

Frank: they are equivalent when I say they are, i.e. for my purpose
... e.g. encryption Provider Agent

Katia: a provider agent provides one or more services Requester Agent

Katia: it's an agent

Frank: it requests services, not tasks

David: you request a service to do something

Katia: the image doesn't say so

Frank: I'll modify the diagram

Scribe: the group settles on "requester agent uses a service" Service

Katia: say "a coherent functionality"

Roger: I'm not sure about the MUST about the concrete provider agent

Hugo: there is no relationship with provider agent

Frank: the diagram is wrong
... I'll change it

Hugo: we should record an issue about what the representation of a service is Service Description

Hao: we could get a service description from a service

Frank: support I have invented a foobar-Hertz service; I have no association with Hertz, have no agent deployed, I just have a choreography

Hugo: but you could still get a description from the URI

Frank: if you had it, it would not benefit you, you wouldn't know what it does

Mike: there's still the question of what the representation is

Hao: if we don't define it, people will invite all kinds of ways to do it

David: you could have more than one description possible

Mike: let's add it to the previous issue

Katia: instead of network location, can we say address?

Scribe: -- Break --

... Discussing http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html?rev=1.111&content-type=text/html;%20charset=iso-8859-1 Service Interface

Frank: remove service tasks

Roger: the interface defines the message types, not the messages Service Role

Hugo: what's the relationship with intermediaries?
... thinking about SOAP roles

Frank: it's more general

Hugo: and why is it linked to p.o.o.?

Frank: the agent doesn't have an awareness of the task

Roger: property is not defined

Frank: we need to connect service role and message

Katia: we should use capability

Scribe: [ Discussions about where capability fits in the picture ]
... Property was taken out of the diagram Service Semantics

Mike: should we say that it's an informal contract?

Roger: why do we say that it is well-defined?

David: let's get rid of it

Frank: it may not be entirely behavioral Service Task

Roger: remove the "choreographed" relationship
... we should remove choreography from description too

Frank: it's ok, it's explanation

2.3.3 The Resource Oriented Model

Scribe: Fixing typos

Roger: there are arrows going both ways in the diagram
... between resource description and resource

Frank: I think that we should say that capability is a resource Discovery

David: I have made some changes
... added a relationship about locating a service description

Hao: but this is resource discovery, not service discovery

Katia: we don't want to generalize discovery too much

Mike: so discovery doesn't belong in the ROM but in the SOM

David: if we make discovery general, we don't have much to say about it

Hao: and that's a good thing

Roger: hold on, you're completely changing the meaning by including human-readable resources
... we should specify that we are using a specialized definition of discovery

Frank: we want to be discovering resources and not only Web services

David: why do you want to limit discovery to machine-readable?

Roger: we had agreed on it

Mike: let's specify that the explanation is WS-specific Discovery Service

Frank: we have a mismatch with the new definition of discovery

David: let's delete the mention of indexes in the relationships

Hugo: let's add a link to the discovery discussion in section 3


Katia: we should remove the QName issue

Hugo: this is an important one

Roger: let's say that the Web uses URIs

Bijan: why opaque? it's like talking about URIs witout saying it
... and a QName isn't opaque, nor is it a string

Hugo: let's add that to the issue too

Scribe: The consensus of the WG is that URIs are the preferred form of identifiers. Representation

Bijan: I don't like the definition

Mike: let's use the one from Web Arch

Roger: please add that a GET returns the representation of a resource Resource description

Scribe: Fixing typos
... -- BREAK --

<dbooth> [Roger started scribing at this point]


Scribe: Afternoon
... Diagram simplified to eliminate concepts not in text. Need to add Policy Description to text.

<mchampion> yinleng, are you here?

<yinleng> yes

Scribe: We have finished section 2. Doing top-down survey of section 3.
... Old version: http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html?rev=1.105&content-type=text/html;%20charset=iso-8859-1#message_reliability

<mchampion> hi yenleng are you ready to call in

<yinleng> I can call in now, but I thought David Booth said that you expected to discuss management on wed 3.30pm?

<mchampion> We can do it either now, or tomorrow. Your choice.

<yinleng> tomorrow then, if that's ok by the group

<mchampion> We are at a convenient point to move to management, and have one more hour on our schedule
... OK, tomorrow 3:30 Eastern (US)

<yinleng> ok

<dbooth> ACTION: dbooth to resize Figure 9 (discovery) because it is too wide to print

Summary of Action Items

[NEW] ACTION: David, Katia and Hugo to finish working on capability during
[NEW] ACTION: dbooth to resize Figure 9 (discovery) because it is too wide
  to print
[PENDING] ACTION: Mike to bring up the issue of location of address
[IN_PROGRESS] ACTION: Frank to update models diagram

Minutes formatted by David Booth's scribe.perl 1.54 (CVS log)
$Date: 2004/01/17 05:23:37 $