See also: IRC log
Present: Erik Ackerman Lexmark David Booth W3C Allen Brookes Rogue Wave Software Roberto Chinnici Sun Microsystems Paul Downey British Telecommunications Steve Graham Global Grid Forum Jacek Kopecky Systinet Philippe Le Hégaret W3C Amelia Lewis TIBCO Lily Liu webMethods Ingo Melzer DaimlerChrysler Dale Moberg Cyclone Commerce Jean-Jacques Moreau Canon Arthur Ryman IBM Adi Sakala IONA Technologies Jeffrey Schlimmer Microsoft Igor Sedukhin Computer Associates Jerry Thrasher Lexmark William Vambenepe Hewlett-Packard Sanjiva Weerawarana IBM Umit Yalcinalp Oracle
Regrets: Dietmar Gaertner Software AG Kevin Canyang Liu SAP Glen Daniels Sonic Jonathan Marsh Chair (Microsoft) Bijan Parsia University of Maryland MIND Lab Prasad Yendluri webMethods, Inc.
Chair: dbooth
Scribe: Sanjiva
<Ingo> Minutes of Oct 9th approved: http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Oct/att-0027/arch-03-10-09.htm
<dbooth> ACTION: 2003-07-31: Philippe to make a proposal for fixing the HTTP binding. [PENDING]
<dbooth> ACTION: 2003-09-11: Philippe to write a response to Mark Baker proposing a property solution to HTTP verbs and ask whether this satisfies his request. [PENDING]
<dbooth> ACTION: 2003-09-18: Philippe, Marsh to review the QA operational guidelines. [PENDING]
Scribe: Philippe gets the weekly spanking: usual response .. but promises to *really* do them before the f2f!
<dbooth> ACTION: 2003-09-23: Roberto, Glen to provide a counterproposal to the current proposal for endpoint references. [PENDING]
<Ingo> Robert did submit a counterproposal. Work is happening, but not done.
<dbooth> ACTION: 2003-10-02: Editors to provide drafts for pub review a couple of days before the Oct 16th telcon. [PENDING]
<Ingo> Editors need some more time for the documents. Part 1 can be published
... in time.
... OK
<dbooth> ACTION: dbooth to check on pub moratorium
<dbooth> ACTION: 2003-10-09: dbooth to sync with JMarsh to make sure RPC style rules gets added to next week's agenda [DONE]
<dbooth> ACTION: 2003-10-09: Sanjiva: send email explaining rational for pattern inference. [PENDING]
Scribe: Discussing Jan F2F - Arthur offers to host in Toronto, but still no decision on where it will be, because we're awaiting word from Glen on whether Sonic can host it.
Scribe: Attr taskforce: no new news
Scribe: New issue: cycle detection - Amy explains and wonders whether cycle detection within schemas is a job for the wsdl processor or a problem (feature) that results in a fatal error .. or a long, slow, painful death resulting in the lifegiving blood of computers called virtual memory.
David: Is Cyclical include sensible? Amy says yes. (Scribe wonders why)
<jeffsch> Shall we create a new issue in the issues list?
Scribe: ACTION: Amy to provide a use-case for cyclical includes.
<jeffsch> Cyclical includes is Issue 94
Scribe: David explains where we are with faults and notes we may have to wait since Roberto isn't here
<Ingo> We should wait until Roberto is back.
Scribe: Scribe explains his recollection but still not clear there's enough info to move forward.
<dbooth> Amy: Messages are 1-to-1 to message references in the MEP, whereas faults are many-to-1 to message references in the MEP.
Scribe: Amy & Umit believe we decided to add a "@name" NCName to name infault/outfault elements to allow bindings to point to specific faults.
... Sanjiva disagrees (per minutes) and chair says "let's continue discussion"
... Amy points out that there can be many faults per message reference whereas there's only one "regular" message per message reference.
... Sanjiva notes that faults can also be made 1-1 if you force users to put all the faults in an xsd:choice
... Amy notes that that's really busted because the semantics are not implied by the xsd:choice
... Umit +1s that view
<Ingo> +1
Scribe: Proposal from Jacek to add an optional @name NCName
... DBooth asks those against this approach to suggest alternate ways that allows users to address the requirement.
... Sanjiva challenges people to give a usecase to support this requirement.
... Roberto concerned about optional name - if its optional then binding guy may be stuck because the interface author was narrow minded.
DBooth: Let's give an action item to someone to come up with usecase. No volunteers. We will wait for a while for someone to do it if not drop this "requirement".
Scribe: Before addressing Amy's proposal for adding 3 patterns, the Chair notes that there seems to be a deeper issue about the pattern stuff .. is there such a thing called a "normative" pattern?
... What does that mean?
<dbooth> We haven't been clear about the normative status of patterns. For example, I noticed:
... Roberto: http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0255.html
... [[
... . . . I disagree with making
... this pattern normative. How about the compromise of having the pattern
... Amy proposes in a non-normative appendix to the patterns spec? We define
... it properly, assign it a URI, use it to elucidate the patterns
... framework, make it available for anybody to use it (if they have
... a binding for it, that is), but it's *not* normative.
... ]]
... Looking back at Jeffrey's suggestion at our last F2F:
... JeffSch: http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0047.html
... [[
... jeffsch: I suggest patterns URIs are like styles, bindings, we don't
... require any of them being implemented; market pressures may cause
... most or all of them implemented in most implementations
... ]]
Scribe: DBooth posts some comments from previous f2f minutes to show Jeffrey's view of what "normative" means.
... (for pattern URIs)
<umit> I think there is a difference between what is normative and what is required. We seem to mix the two concepts.
Jack: Normative means binding from the URI to the semantics in the spec for that URI is fixed.
Scribe: Sanjiva says +1
<Roberto> I hope [required] implies [normative].
<umit> I believe that is implied.
<jeffsch> Agree required => normative
... +1 to Umit that we are not (yet) clear about normative =?=> required to implement
DBooth: 2 issues: (1) what do we normatively define, (2) what do we normatively require a wsdl processor to understand
Amy: requirement for a specific pattern to be supported comes from a particular binding
DBooth: does this mean we don't have to require a wsdl processor to understand particular bindings?
Amy: no such thing as an "abstract" wsdl processor - every wsdl processor eventually supports some bindings and those are what really makes certain patterns required.
DBooth: we are basically agreeing with the view suggested by Jeffrey
Roberto: agrees
DBooth: we appear to have consensus. Struggling with phrasing the consensus ;-)
Umit: we need a complete sweep of the spec to clarify what is normative, what is required and perhaps what is not required. Roberto use an example of alternative schema languages as a non-normative thing in the spec.
DBooth: When we normatively define a MEP, if that MEP is used in a WSDL doc then it MUST have the meaning defined in our specification.
Scribe: We appear to have consensus.
... Now discussing Amy's new patterns
... Roberto asks how we decide how many normative patterns to add?
<jeffsch> When we loop back to these patterns, I have a question about the third pattern.
Scribe: Amy suggests we allow people to add patterns to the list ..
... ack
Roberto: clarification on how you treat normative/non-normative stuff @ last call time
Philippe: normative and non-normative sections are treated equally at last call time
Scribe: Important point during pattern discussion: with message-triggers-fault: a fault terminates the pattern immediately
<scribe> ACTION: Part2 editors to clarify when faults terminate patterns (or not).
... With fault-replaces-message, no issue because the pattern is implicitly terminated because the message flow has been changed.
<dbooth> Amy's proposed patterns:
... robust-in-only
... robust-out-only
... asynch-out-in
Scribe: Objections to adopting Amy's patterns? None. We have accepted the proposed 3 patterns.
<scribe> ACTION: Part2 editors to update pattern spec accordingly.
... Chair adjourns the meeting 6 minutes early ;-)