Raw telconf minutes, 20020516

Minutes
Two version of minutes.
Jonathan's is the latest one, fixed link to stylesheet.
Philippe to change authorization (private by default).
KevinLiu had sent regrets.

Action items
Waqar: add use case: DONE.
Waqar: post new draft: DONE.
DavidB: DONE.
ACTION: DBooth to find out how to get registration list.
Editors: insert actions: DONE..
Sanjiva: import: PENDING.
Sanjiva: optional parts: PENDING.
Jonathan: reply to Mike Deem: DONE.
Jonathan: post AM email: DONE.

Make arrangments for June FTF asap.

No new issues.

Abstract Model
Members: Youenn, JackK, KeithB, Krishna, Prasad, Waqar, Sanjiva.
Leader: only Krishna has volunteered as leader, but will not attend FTF.
Waqar: suggest pick one based on presence at F2F.
JackK: no leader for XMLP task forces. Telcon setup was done on best effort basis, as reports during main telcon. I could present at the F2F.
Jonathan: suggest you are appointed as leader.
JackK: ok.
?: remote attendance possible?
Jonathan: not sure.
Waqar: not very useful.
Jean-Jacques: somewhat disagree; enjoyed remote F2F, at least some of it.
Waqar: sound bad.
Jonathan: did you have IRC?
Waqar: no.
Jonathan: suspect this will get better when we know each other better.

Issues
Jonathan: little traffic this week.

Message part issue
Jonathan: Sanjiva: message part: are we converging?
Sanjiva: no real progress; waiting for note from KeithB.
Jonathan: you an advocate for keeping messages as is, and Keith is for replacing by complex types?
Sanjiva: i am for keeping functionality as is; would be ok if there is a solution with complex type, but have not seen one so far. 
Jonathan: so waiting for a proposal which works.
Prasad: is this for 2.0 or 1.2?
Sanjiva: need to make decision soon, so keep message and improve later.
JeffS: thought 1.2.
Jonathan: thought had agreed to keep message, but improvements.
Sanjiva: would need to drop elements, would simplify problem.
Prasad: how to capture doc, RPC, etc. It is more than optional parts.
Jonathan: closed this part of the issue yesterday, and were to create a new issue.
Jonathan: are we done, or should we do something better? will the AM help?
JeffS: should not drop it.
Prasad: can make proposal, if that helps.
Sanjiva:
JeffS: Track issues separately. People want to explore some fine design points. Should explore them. For example, discussion maintaining discussion RPC vs. document.
Jonathan: done for today? Action on Sanjiva?

Extensibility issue
Jonathan: last work from Roberto.
Robertor: not much feedback.
Jonathan: pls recap.
Roberto: how the processor deals with extension. 1) enable annotations on most elements. All children would be annotations. SHOULD be safely ignored. Solved meta-data issues. 2) Architecture extension. Covers binding extension elements. Defined semantics. Defines what a binding extension should be. Upon processing, binding is unusable if extension is not understood. Can also be applied to type attribute, or any other type from any type system. 3) Language extension. Allowed to modified the semantics of WSDL. Apply different processing rules to the language as a whole. Need a declaration at the top, so processor knows there is a need for a specific extension, and can reject the document if not understood right from the start.
Roberto: Igor thought extensions were good, and should have optional extensions. If have optional language extensions, maybe subsumes language extensions.
Igor: 3 points. 1) (main point) optional extensions. 2) Classification: too complex. 3) (minor point) location mechanism.
Roberto: tried to deal with rules for how to process extension, hence my classification.
Igor: so no classification of extensions, and make them optional.
Roberto: ???
Igor: binding extension should be required in header. Since must stop if cannot access service.
Roberto: but could have several bindings and several ports. Not understanding one should not prevent you from using another.
Igor: processor would know with namespace.
Sanjiva: agreement: we will provide some extensions, other will provide others. Builtin extensions are like java.lang, automatically included. Would be annoying to specify binding as an extension.
Igor: agree.
Roberto: implicit declaration.
Sanjiva: would be annoying to say: use XSD and SOAP.
Igor: security is a good extension candidate.
Jonathan: if knows about extension, processor continues?
Igor: language extension if for meta-data. Annotations give you, e.g a link to a UML model.
JeffS: but no different as far as processing?
Igor: yes, there is. The UML annotation is not for procesor but for designer.
Jonathan: so difference is between human and processor. Why distinguish?
Prasad: for example, SOAP with my own binding would come as a language extension, not annotation.
Jonathan: ???
Igor: say wanted to extend Java with a "foreach" construct, and also ability to add attributes, eg. this attribute is "SOAP encoding". The latter would be an annotation. The former an extension.
Jonathan: think we don't have a clear definition for extension. Why the difference?
Igor: an annotation might help the processor. The extension is directly for the processor to understand extra information; it's not a hint, but a new construct. Propose to separate the issues.
Jonathan: ok, nail down language extension first. Annotation will probably not give you much; people will likely use optional extensions as annotations.
Prasad: annotations don't have to be declared.
Igor: equivalent to our SOAP binding element.
Jonathan: could design it differently, for example simply ignoring namespace for that extension.
Prasad: how do we separate?
Waqar: running in circles.
Jonathan: agree. Do we need a new proposal for language extensions? Probably close to Roberto's proposal?
Igor: modify Roberto's proposal.
Roberto: can write this up after the call, and email it.
Jonathan: ACTION: Roberto to post revised proposal, annotations out, revised extension. Sounds good?
Agreement.
Jonathan: looks like we're really close.

Remove sollicit-response issue
Prasad: would like to do it. Little evidence any one needs them.
Igor: ???
Prasad: not a simple question of leaving it in or not. Propose remove them from draft, and ask for feedback.
JeffS: do you want feedback now?
Prasad: yes!
Igor: ???
JeffS: don't think we'll do events in 1.2
Igor: looks like you would need these at the lower leve.
Prasad: why reply do you take if have several replies.
JeffS: feels not well defined today, and don't think used today.
Prasad: maybe the two are related.
Igor: currently, not using them since WSDL is new.
Jonathan: JeffS?
JeffS: understand concern, agree definition is not clear enough. There are efforts underway, we might find these people have constructive input. E.g. UPNP forum would like to use WSDL for Web Devices, have events, might not wait for W3C. Previous orchestration work may have input as well. But wouldn't remove them if don't have events.
Waqar: events are useful. One-way output message, etc. may not be enough, but important paradigm, so should not discard them.
Igor: have them as extensions (events)?
Prasad: UPNP guys should forward their WSDL event work.
JacekK: agree events are important, but not in scope of WSDL, since composed of one-way messages and response only.
?: events need subscription.
Igor: can be defined within our scope.
JeffS: maybe simpler solution. Say what an event is (a message arriving), but not say how to suscribe. So tools would understand the type of the message that would be coming.
Igor: agree. No description today that tells you who your messages will be conveyed. And leave subscription as extension.
Roberto: had same argument last week. Would complicate processors. Would be advantageous to have only 2 operations.
Waqar: would we be able to model services from EJB, etc. with what we have currently? Need solid use case. Fixing deficiencies and provide extensions would be better.
?: ?
Igor: maybe should come up with extension for events, and see if works.
JeffS: agree, but confused about extension. Is extension in our namespace, or non-normative?
Waqar: need requirement.
Prasad: decide later where to put it.
Waqar: come up with solid use scenario.
Jonathan: sounds like a plan.
Igor: can start with extensions, and see if what we have is sufficient.
?: define first what to do.
Prasad: not just do with extension.
Waqar: agree. Process to identify deficiencies, so let's go along.
Jonathan: action item?
JeffS: define more precisely what input output mean, and specifiy what this means for bindings, relative to events.
Prasad: model events first.
Waqar: produce use case scenario and sample situation in terms of requirement.
Prasad: go both directions.

Adjourned.