See also: IRC log
Chair: MikeC & DaveH
<dbooth> Scribes: Unknown (morning), Mike Mahan (afternoon)
<DaveH> WSA goals for the next 10 days:
... CALL TO ORDER!
... ACTION: doug to publish mintes from 11/7 asap
ColleenE: We should be specific in our response
<hugo> Issue is: http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x390
DougB: Forward "XMLP Response to comment 1" and change the the I to We
DaveH: next "Clarifications about how resources on the web are added"
DaveO: need both original URI and the representation is
... treated like it is a cache
DOugB: Proposes Describing the use case and letting XMLP discuss
DaveO: Proposes acknolging the 3 bullet points and say there isn't enough deatail and offer additional detail for XMLP to consider
Resolution: Table pending further work from DaveO, ChrisF and anyone else to bring back specific wording before the end of the meeting
DaveH: Issue: That our arch doc needs to deal with the issues between Representations and resources.
<DaveH> Add to this the propeor understanding of
attachments and other temporal data entities.
... ISSUE: define resource/representation and attachments
... bummer...zakim did not see this
DaveO: When is something a representation and when is something a resource?
<HaoHe> a resource is a concept
... a resouce can have many representations
<dougb> Hao, discussion here is focusing (mostly) on transitory resources or representations. We're also wondering how / whether to ask TAG about general issue (POST request for example).
<DaveH> Chais encourage positioning papers on the resource/prespesentation distinction and how the toppic can be presented in the arch doc
<HaoHe> that sounds interesting, we have quite a few examples in Thomson.
MikeC: Is there anything missung from the agenda?
DaveH: encourges every one to look at the agenda and if your favorite topic is not there, please bring it forward. Also review the topics in the agenda and create possible wording for each Topic.
Scribe: The WSAWG would like to thank the Admin team for
their spam reduction efforts.
... --- BREAK ---
MikeC: Proposal we want to make sure the first part of the arch document is well thought out and useful, so I like to open the floor for word smithing.
DavidB: Would like to get some feed back on some updated diagrams that he and ChrisF worked on.
DaveH: any concerns?
<HaoHe> I want my "messaging without SOAP"
Scribe: Remove "Web services reference" from the abstract
part of the arch document in sentence 2.
... We are reviewing the state of the abstract statement in the arch document
... Action: Issue: the second sentence of the abstract requires additional consideration by the WG.
<geoff_a> How about "identifies components, describes properties and constraints of these components, and defines the relationships between them"
Scribe: ACTION: to the chairs add toa future agenda the
second sentence of the abstract requires additional consideration
by the WG
... We are discussing the name of section 4 of the arch doc
... Is Section 3 of the arch. doc. the primer?
DaveO: what is the intent of section 4?
ColleenE: Section is suffering from multiple author syndrom.
MarkJ: Could be called the "principle of web services architecture"?
DougB: suggests that section 4 is the architecture document the rest is primer
DaveH: there are 2 purposes served by the arch document the web services architecture and the relationship the the web architecture.
MikeC: What is the purpose to section 3 and what is the purpose of section 4 are the questions at hand.
markJ: doesn't see section 3 as the primer.
daveO: retracts the term primer as it is not the correct term.
<dbooth> I suggest we call section 3 "Architectural Overview" a
daveH: our goal is to word smith the document for the AC so it can stand we are not trying to restructure.
Resolution: DavidB proposal accepted.
<dougb> I mentioned a suggestion for future editorial work: Placing the bulk of what's now in section 3 after section 4, describing the components and relationships emerging from the principles and constraints in section 4. DaveH's comment was to clarify my proposal as not appropriate for the current effort. Friendlly amendment accepted.
<geoff_a> Anyone got the URL for the latest Web Architecture draft?
Proposal: add purpose statement to all sections specifically section 4
Scribe: Editor will at his discression add purpose statement and post proposed text to the group
Scribe: Option 1 to kill the whole first sentence of the first paragraph.
<HaoHe> Can we go through the doc section by section?
Scribe: option 2 is to delete "is expanding rapidly"
<jeffm> I think this is the url for the latest
version of the arch doc DavidO referred to:
... Please correct if necessary
<dougb> Jeff, newer version (not yet published externally) is much better - http://www.w3.org/2001/tag/2002/WD-webarch-20021107
Resolution: First sentence will be deleted
Scribe: Section 1 second ParaGraph
... DaveH : when are we going to tackle the reference architecture meaning.
DaveH: this document is definitive and describes
Scribe: ACTION: Chairs schedule the discussion on the reference architecture definition
<dbooth> I suggest that we use the term "architecture" instead of "reference architecture" throughout, unless and until we agree on the need for the additional term "reference architecture".
<Heather> Rathole 1: what is a reference architecture
Resolution: We will leave it Section 1 paragrah will be left alone until the reference architecture rathole is completed.
<Heather> Rathole 2: what abstraction away from the implementation do we want this arch to exist: abstract, general, concrete
DaveH: We can't talk about reference architecture until we have a architectual taxonomy.
<DaveH> rathole 2 refinement: what taxonomy of architecture
Scribe: Moving on
... Section 1 Paragraph 3
<dougb> resolved: don't bother "fixing" existing mentions of reference architecture (in para 2) until we've had the rat hole discussions.
Scribe: Section 1.1
<dbooth> Someone got the document URL again please?
DougB: For more information on the need of the architeture reference the charter
<hugo> the charter says: "Several proposals have
been published by different organizations to address different
parts of the required task. The goal of the Web Services
Architecture Working Group is to lay out a coherent architecture,
by producing architectural documents and advising W3C regarding
work in the Web services area."
... we may want to add something stressing interoperability
Scribe: ---- LUNCH BREAK ----
<dbooth> My proposed conventions being discussed:
... Option 1: Allow the word "component", but never use it to mean "artifact".
... Option 2: Never use the word "component" at all.
... Option 3: Provide multiple definitions of "component" that are context sensitive.
... Option 2a: Use the word "agent" instead of "component".
... Option 3a: Use "component" sparingly, and try to be very clear about what it is supposed to mean.
<Heather> rathole 3: are events covered by actor or artifact or action?
<dougb> ACTION: editors to update diagrams with reinforcements for their biases from David Booth's (new, updated) suggestions document
... DaveH: A role is a set of responsibilities taken on by an actor.
... Proposed definition of role: An abstraction of an actor that has responsibilities or can perform actions.
<dougb> excellent suggestion from Chris: Role is an abstration. (period, dot, exclamation mark)
<dbooth> Proposed def 3 of role: An abstraction of something that has responsitilibies and that is instantiated by an actor.
<chrisf> Role: an abstraction of a (set of)
responsibility that is assumed by an actor/agent
... Role: an abstraction of a set of responsibilities that is intended to be fulfilled by an agent
<dbooth> Chrisf, can you put a noun in it? Responsibilities are just verbs.
<dougb> From http://www.m-w.com/cgi-bin/dictionary:
responsibility Function: noun
... Inflected Form(s): plural -ties
... From Date: 1786
... 1 : the quality or state of being responsible : as a : moral, legal, or mental accountability b : RELIABILITY, TRUSTWORTHINESS
... 2 : something for which one is responsible : BURDEN
<dbooth> Proposed def 4 of role: An abstraction of
an entity that has responsibilities.
... Proposed def 5 of role: An abstract entity that has reponsibilities.
Scribe: 4th paragraph of section 3.1
<geoff_a> 7/msg dougb If a Web Service does not require SOAP, WSDL, or XML messages, is there an unambiguous term for a web service constructed in terms of the HTTP/WSDL/SOAP/XML stack?
<MartinC> a ws-i basic profile web service!
<soliton> What about a Web Services that does not require SOAP, and WSDL?
... "The Service Requester obtains the service description either locally, directly from the Service Provider (if it is already known to the Service Requester), or it uses a find operation to retrieve the service description from a discovery agency (i.e. a registry or respository). The Service Requester then uses the service description to bind with the Service Provider and invoke or interact with the Web Service implementation."
<hugo> soliton, this has been recorded as an issue: the definition and its scope
<Hao> hugo, what is the current topic? Is igor giving talk now?
Scribe: currently wordsmithing the arch doc
<dougb> we're on 4th paragraph of section 3.1 (2nd
after the bullets)
... who is doing the real time editing?
<DaveH> time for heather
Scribe: finishing up with wordsmithing up to 3.2
<dougb> for the rat hole (I hope not) trailer park: We should probably define "Header: generic term for in-band metadata." in our Glossary to avoid historical "header / summary / items / trailer" orderings and distinctions.
<DaveO> Doug, I tend to agree. We need to
differentiate between http headers and soap headers.
... DaveO wrote down the following actions for the editors 1. Write material to explain purpose of each chapter.
... 2. Take text from Charter into ws-arch for rationale for why an architecture group
... 3. Replace component with agent
... 4. Change diagrams to show revised iconography.
... 5. Glossary reference to web arch for software agent.
... 6. Fix initial two diagrams into 1.
heather: if you are to have a managable web service, the
STD models the service execution env
... difficult to define the management aspects without having core state concepts
jeffM: can't we adopt dmtf or other management forums
heather: we need an abstraction above ejb or other service incarnation
<DaveH> Is there a management use case that I have overlooked?
geoff: this seems like a classic case of blessing the dmtf model and moving on - since this is a subset of their definitions
<Heather> The MTF owes a management use case
... will cover in next presentation
ericn: existing management models don't map to WS
geoff: dmtf has created CIM definitions which should apply
martin: we should pick an existing model
<dbooth> The three MTF documents are also available
igor: we did look at that, existing models aren't sufficient
<dougb> ?? in what respect(s) are existing service / container models insufficient?
heather: wants inclusion of service lifecycle into WS arch doc
martin: lifecycle is fundamental to the basic architecture
<dougb> for those on call, current presentation is the images contained in the http://www.w3.org/2002/ws/arch/2/11/W3C.MTF.ServiceLifecycle.20021111.htm document
daveo: tcp is fundamental but we don't talk about it
daveh: what happens when a service disappears ... this is why we need lifecycle
daveo: should portions of the lifecycle be in the basic arch?
<DaveH> I belive that it should have the same
visabilty for same reasons as discovery
... what are the properties of the basec arch?
dougb: is current WS definition is at odds with lifecycle
geoff: do not confuse the states a services may enter vs. service properties which are manageable
<DaveH> how are they at odds?
igor: basic states, up & down, are managable
<dougb> also: we're dealing with a distributed architecture: from an external viewpoint, can't tell if something is down or unreachable
geoff: can up & down be defined operationally - from a behavioral perspective
heather: up & down is defined as the ability to take
... the down state doesn't mean it is not observable
<geoff_a> observably "up" or "down" is linked to the QOS supported by the transport - without reliable messaging, I can't necessarily tell the difference between "down" and "slow"
daveh: we haven't identified constrainable properties
... paragraphs on properties on management and discovery are needed
heather: maybe the extended vs basic distinction is bad
chris: from a basic arch perspective, the triangle is
simple to understand and implement
... no need for sec, management, qos, etc
... basic is the essence of the arch
... doesn't see lifecycle in the basic arch
martin: identity is basic and is a property - and so is lifecycle
daveh: you get some sec, management, and lifecycle for free just by creating a service
chris: but that is not arch
heather: exposure of the states, is the management
daveh: all the features are indroducing new managable properties of the arch
<DaveH> not just manageable, but constrainable and therefore of architectural interest
<Heather> Can we make this an issue?
daveo: whether a service is avail is applicable to every WS. But we can make progress without going there
chris: what are the properties we are trying to acheive here
Scribe: [AI] Issue: is management part of the basic or an extended WS architecture
heather: moving to details of what we want to manage
... what to manage is really needs to be discussed with the whole WSA group
... both the service and the service env can collapse
glen: diff between service provider and service env?
<geoff_a> rathole #3 what...?
... We need to think about the principle of "separation of concerns" here
<DaveH> good point
<dougb> service environment makes sense but should be plural and (maybe) layered: for example, SOAP provider | application server | operating system | machine | cluster
jeff: what is the business owner
heather: hosted service/client needs to access the env
... what are the implications for management for hosted service concept
<dougb> ? does awareness come up with respect to both client or service and its environment and client being aware of service environment (and visa versa)?
jeff: if a client has responsibilities, then the entitiy is no longer ignorant of the env
<dougb> confused: which of my options are we currently discussing?
igor: diff between implicit and explicit responsibilities
geoff: the boundary of the manageable service and the service logic, where is it?
Scribe: glen" +1
heather: the management data for a service is separate from the app level logic
ericn: what are the benefits of management to the basic arch