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
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
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
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
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
Katia: a provider agent provides one or more services
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"
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
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
Frank: remove service tasks
Roger: the interface defines the message types, not the messages
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
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
Roger: remove the "choreographed" relationship
... we should remove choreography from description too
Frank: it's ok, it's explanation
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
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
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.
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
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