See also: IRC log
Present: Erik Ackerman Lexmark Mike Ballantyne Electronic Data Systems David Booth W3C Allen Brookes Rogue Wave Software Roberto Chinnici Sun Microsystems Glen Daniels Sonic Software Paul Downey British Telecommunications Dietmar Gaertner Software AG Jacek Kopecky Systinet Philippe Le Hégaret W3C Amelia Lewis TIBCO Kevin Canyang Liu SAP Lily Liu webMethods Dale Moberg Cyclone Commerce Jean-Jacques Moreau Canon Bijan Parsia University of Maryland MIND Lab Jeffrey Schlimmer Microsoft Igor Sedukhin Computer Associates Sanjiva Weerawarana IBM Umit Yalcinalp Oracle Prasad Yendluri webMethods, Inc.
Regrets: Youenn Fablet Canon Jonathan Marsh Chair (Microsoft) Ingo Melzer DaimlerChrysler Arthur Ryman IBM Jerry Thrasher Lexmark William Vambenepe Hewlett-Packard
Chair: DBooth (filling in for JMarsh)
<sanjiva> I have to drop off today in about 30 mins .. apologies.
... That also means I can't scribe :-(
Scribe: minutes approved as posted
<dbooth> ACTION: 2003-07-31: Philippe to make a proposal for fixing the HTTP binding. [UNKNOWN]
<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. [UNKNOWN]
<dbooth> ACTION: 2003-09-18: Philippe, Marsh to review the QA operational guidelines. [UNKNOWN]
<dbooth> ACTION: 2003-09-23: Roberto, Glen: provide a counterproposal to the current proposal for endpoint references. [PENDING]
<dbooth> ACTION: 2003-10-02: Part 2 editors to replace "broadcast" with "multicast" in descriptive text. [DONE]
<dbooth> ACTION: 2003-10-02: Alewis should provide write-up of additional patterns for further discussion. [DONE]
<dbooth> ACTION: 2003-10-02: Editors to provide drafts for pub review a couple of days before the Oct 16th telcon. [PENDING]
Scribe: Registration for Nov f2f open. Please register.
Scribe: Please register
... F2F meeting ends at noon on Wednesday.
... January F2F: Toronto or Boston
... Waiting for confirmation from Glen and Arthur
<scribe> ACTION: Glen to report on whether Sonic can hold January f2f
Scribe: Skipping QA, being dealt with by JMarsh
Scribe: No new issues
Scribe: Proposal from Sanjiva
<jeffsch> (No objection here)
Sanjiva: no feedback
<sanjiva> Silence is consensus?
Scribe: No objection to incorporating Sanjiva's proposal
Sanjiva: syntactic change, messageRef m can result in fauts i1, i2, etc.
... no objection so far
... detail elements from list of QNames to repeating messageRef with same ref values
Scribe: No objection to incorporating Sanjiva's proposal (part 1)
Sanjiva: renaming to fault
... more controversial, can live without
DBooth: faults defined differently from messages, don't have names
... fault is identified by message it replaces
Sanjiva: context of any other message out of scope
Tom: no syntax, only detail element, QName pointing to schema
<dbooth> So under the fault-replaces-message rule, the fault would be indirectly identified by the name of the message that it replaces.
Glen: maybe keep notion of abstract fault name, for tools
Sanjiva: however patterns don't belong to WSDL?
Glen: "getStockQuote" is your particular name
Amy: need extra attribute
Glen: NCName is fine
Sanjiva: inconsistent doing it for one, not the other
<umit> +1 to adding a fault name.
Glen: look at Java, can throw multiple or no exception
... could add restriction over SOAP to detail element
Amy: how much belong in bindings?
Sanjiva: can't do it in bindings, unless have an explicit name
Sanjiva: can we open a new issue?
Glen: why not complete the proposal?
Roberto: required or optional attribute?
Glen: maybe at abstract level should only have name of the fault
... and in binding, put fault details
Tom: like exceptions in Java
Sanjiva: so don't give them element QName, give them names?
DBooth: sounds like we need more discussion by email
... also, other aspect, since not in Part1, would there be other ways people to add these messages?
... any other issues?
Kevin: add name attribute to fault?
Sanjiva: option 1: NCName to fault
... option 2: give symbolic name only, bind later
Kevin: our developpers want faults uniquely identifiable in WSDL
Sanjiva: this is addressed by both proposals
DBooth: continue by email
Sanjiva: Tom and Glen, do you think both options are feasible
Tom: need to think more about how it affects the interface
... willing to be convinced that having detail element would be enough to generate signature interface
<sanjiva> I have to drop off now .. I'm +1 to adding the patterns that Amy sent but need more time to understand them precisely. (Given how poorly I had understood the basic patterns I am sure there's subtlety I haven't grok'ed.)
Scribe: Not enough time for people to read; discuss next week
Scribe: ACTION: Sanjiva: send email explaining rational for pattern inference
Jeffsch: no issue with this
DBooth: related to discussion on faults?
Jeffsch: thinks this issue can be addressed now, to get us back on solid footing
Scribe: Any objections?
DBooth: make more consistent the binding of faults
Roberto: to mirror the abstract level
DBooth: modulo changing name to messageRef
Scribe: Any objections?
... No objection
<jeffsch> Added to the edtodo.html
Jack: need to cater for additional type systems
... jeffsch commented on extensibility
Glen: always been going in wrong direction in allowing Infoset-based descriptions for messages
... like what MTOM/PASSWA does
<jeffsch> I strongly agree with Glen's point about the value of the Infoset-level of abstraction, and expect there to be diminishing returns as we continue to generalize.
... However, we have multiple constituencies in the WG, and are being asked to find a way to describe significantly different architectures.
<bijan> I suspect that OWL types might need some help, but I'm completely unclear
<JacekK> ACTION: Bijan to look into message extensibility issues (Appendix E, Jacek's review) wrt RDF data, and discuss with Jacek
Umit: still being discussed by subgroup
... discussing new approach; not sure when can report back, maybe a week
DBooth: any one can report status?
... skip next one as well
Jeffsch: made significant progress in the way WSDL works
Jeffsch: very exciting for developpers
<bijan> +1 again!
Jeffsch: suggest seat back before lastCall, and examine if new names are not necessary for the new component model
Tom: willing to have an open mind, but concerned about changing solid existing concepts
... objecting at least to operation
... would object any draft with name change violently disagree with
... wouldn't oppose overwhelming majority though
DBooth: I suggest that JMarsh (as chair, since he is responsible for sequencing our work) consider the suggestion by Jeffsch to revisit our naming once our major work has been performed
<JacekK> directly on the issue of renaming operation to messageExchange, I think that the current name, "operation", does have some additional semantics over messageExchange, and that those semantics fit well what we are modeling, so I want to keep the name.
<bijan> Its' *considering* renaming
Umit: disagree with Jack; no operation in JMS, for example
<bijan> With perhaps deferring such discussions *until* then
Umit: strong supported of changing that name
Jack: would have to rename interfaces as well
... disagree that we are just modelling message exchanges; would object
Roberto: +1 to Jeffsch
<dbooth> ACTION: JMarsh to consider adding JeffSch's suggestion to revisit naming questions later, after subtantive work is done, to future agenda
<bijan> Ooo! Good point Roberto!
DBooth: continue by email and move on
<Roberto> I'm actually -1 to Jeff's proposal if it comes too close to last call
<jeffsch> Agree that there's expense to implementations and specification to change names; not horrible, but pesky; completely comfortable with scrubbing names before last-call.
Glen: has been travelling
<bijan> Well, that cuts both ways. If I have an "operation" object, and operation 2.0 is different than 1.1...
... I need some differentiated anyhoo
Glen: elements to refer instead of property syntax
... volunteer to write up extra text to describe feature's architecture; still pending, unfortunaltely
Philippe: did not yet send email to Mark Baker
<JacekK> ACTION: Jacek to discuss Bijan's action off-line with Bijan
Scribe: Meeting adjourned
<dbooth> ACTION: dbooth to sync with JMarsh to make sure RPC style rules gets added to next week's agenda