15:00:54 <RRSAgent> RRSAgent has joined #ws-desc
15:01:17 <JacekK> JacekK has joined #ws-desc
15:01:27 <dbooth> zakim, this is desc
15:01:29 <Zakim> ok, dbooth
15:01:32 <sanjiva> sanjiva has joined #WS-Desc
15:01:35 <dbooth> zakim, who is here?
15:01:36 <Zakim> I see A.Ryman, ??P1, K.Liu, ??P5, S.Searingen, Steve.Lind, DavidB, ??P14, Jonathan, GlenD, ??P16
15:01:38 <Zakim> +??P18
15:01:54 <marioj> marioj has joined #ws-desc
15:01:57 <SteveLind> SteveLind has joined #ws-desc
15:02:07 <Zakim> +??P27
15:02:09 <Zakim> +??P25
15:02:15 <JacekK> zakim, ??p27 is probably m
15:02:16 <Zakim> +M?; got it
15:02:16 <sanjiva> zakim, ??P27 is sanjiva
15:02:18 <Zakim> sorry, sanjiva, I do not recognize a party named '??P27'
15:02:18 <Zakim> +D.Gaertner
15:02:30 <JacekK> zakim, ??p27 is me
15:02:31 <Zakim> sorry, JacekK, I do not recognize a party named '??p27'
15:02:32 <sanjiva> zakim, ??p27 is sanjiva
15:02:33 <Zakim> sorry, sanjiva, I do not recognize a party named '??p27'
15:02:37 <Zakim> + +1.408.406.aaaa
15:02:39 <JacekK> Sanjiva, I think you are 25
15:02:43 <sanjiva> ok!
15:02:50 <Zakim> +Philippe
15:02:57 <JThrasher> JThrasher has joined #ws-desc
15:02:57 <JacekK> zakim, m is JacekK
15:02:59 <Zakim> +JacekK; got it
15:03:00 <sanjiva> zakim, ??P25 is me
15:03:01 <JacekK> zakim, mute JacekK
15:03:02 <Zakim> +Sanjiva; got it
15:03:02 <Zakim> JacekK should now be muted
15:03:06 <Zakim> +J.Thrasher
15:03:09 <Zakim> +Igor.Sedukhin
15:03:17 <Zakim> + +1.512.868.aabb
15:03:39 <Allen> Allen has joined #ws-desc
15:03:57 <JacekK> zakim, unmute JacekK
15:03:58 <Zakim> JacekK should no longer be muted
15:04:14 <JacekK> zakim, mute JacekK
15:04:15 <Zakim> JacekK should now be muted
15:04:22 <JacekK> zakim, mute JacekK
15:04:23 <Zakim> JacekK should now be muted
15:04:28 <Zakim> +Dale.Moberg
15:04:37 <igors> igors has joined #ws-desc
15:04:43 <Zakim> + +1.716.383.aacc
15:05:57 <DonWright> DonWright has joined #ws-desc
15:06:19 <Philippe> Dale sent regrets? so Dale.Moberg is not Dale Moberg...
15:06:22 <Zakim> + +1.530.219.aadd
15:06:23 <Zakim> +??P49
15:06:29 <Zakim> +D.Wright
15:06:41 <Don> Don has joined #ws-desc
15:08:26 <Zakim> +Don
15:08:53 <youenn> youenn has joined #ws-desc
15:09:28 <Zakim> - +1.512.868.aabb
15:10:41 <Zakim> +A.Sakala
15:11:06 <bill> bill has joined #ws-desc
15:11:06 <Don> Minutes approved.
15:11:19 <adisakala> adisakala has joined #ws-desc
15:11:23 <jeffsch> dbooth fix linking to registration for face-to-face [done]
15:11:29 <JacekK> zakim, unmute JacekK
15:11:30 <Zakim> JacekK should no longer be muted
15:11:35 <Don> Action Items: DONE [7] 2002.05.16 DBooth to find out how to get registration list.
15:11:41 <jeffsch> jeffsch has joined #ws-desc
15:12:03 <Don> DONE [8] 2002.05.16 Roberto to post revised extensibility proposal, annotations out, revised extension.
15:12:03 <Zakim> - +1.530.219.aadd
15:12:13 <JacekK> zakim, mute JacekK
15:12:14 <Zakim> JacekK should now be muted
15:12:23 <dbooth> Meeting: WS Description Teleconference
15:12:37 <dbooth> Topic: Usage Task Force
15:12:58 <Zakim> + +1.530.219.aaee
15:13:15 <Zakim> +??P56
15:13:17 <Zakim> +K.Ballinger
15:13:35 <bill> bill has joined #ws-desc
15:13:43 <dbooth> Sanjiva: The document is out.  Two weeks have gone by.  The last telecon was organizational.  I hope something will happen today.
15:14:17 <Zakim> + +33.2.99.87.aaff
15:14:28 <dbooth> Jonathan: Waqar also sent another draft of usage scenarios.
15:14:48 <dbooth> ... Should we publish it now?  Discuss it more at F2F?  Hold off?
15:15:19 <dbooth> Waqar: I saw the use case doc from the Arch group and it contained a lot of the use cases that we have, and i added them.
15:15:30 <dbooth> ... How will that synchronization take place?
15:15:49 <dbooth> JM: That's up to us.
15:16:16 <dbooth> JeffM: I think we should publish it with a disclaimer saying that it is the current state and we're working with the Arch group on it.
15:16:49 <dbooth> JM: Any objections to publishing the usage scenario doc with a note that JeffM describes?
15:17:15 <dbooth> Arthur: Has the revision included the updates?
15:17:47 <dbooth> Waqar: I made a number of updates, but it didn't incorporate all.  Should we discuss the ones that were omitted?
15:18:13 <dbooth> ... I incorporated the editorial comments, but not all of the more substantive things, because some were not clear.
15:18:43 <dbooth> ... I've asked for clarification, but haven't yet received much feedback.  So I didn't know what to do about it.
15:18:44 <Zakim> - +1.530.219.aaee
15:18:45 <Zakim> +??P61
15:18:56 <dbooth> ... I was hoping that it would be reviewed and I would get more feedback.
15:19:01 <Zakim> + +1.512.404.aagg - is perhaps MikeBallantyne?
15:19:37 <dbooth> Arthur: There was nothing that i strongly objected to.  My comments were mostly suggestions and clarifications.  I have no objections to publishing.
15:20:00 <dbooth> JM: With no other objections noted, let's go ahead and publish it.
15:21:01 <dbooth> ... Eventually the usage scenarios will migrate to the Arch group, and this group will only have specific use cases.
15:21:08 <dbooth> ... That transition may be a little awkward.
15:21:47 <dbooth> Sandeep: The other good thing about the other group taking it up is that the task force is pretty dedicated, so I think they'll do a better job than we were able to do.
15:22:04 <dbooth> s/the/their/
15:23:00 <dbooth> Philippe: I'd like to sync the status with the one we included in the requirements doc, and I'm not sure if I should modify that without the agreement of the WG.
15:23:16 <dbooth> JM: Anyone want to review philippe's edits before we publish it?
15:23:29 <dbooth> (None noted)
15:23:35 <dbooth> JM: We'll go ahead then.
15:23:57 <dbooth> ACTION: Philippe to update status section of the requirement's doc
15:24:06 <Zakim> -Dale.Moberg
15:24:21 <Philippe> ah, Dale was Sandeep.
15:24:23 <dbooth> ACTION: Philippe, Jonathan, Waqar to work on getting the usage scenarios published
15:24:39 <Philippe> action to myself: fix the bridge data
15:26:07 <dbooth> JM: THere was an issue from Joyce about overloaded methods.
15:26:14 <dbooth> Keith: I think we should discuss it.
15:26:36 <dbooth> ... I don't  like the term "overloaded methods" because WSDL is not exposing methods directly.
15:26:49 <dbooth> ... They are "operations".
15:27:05 <dbooth> JeffM: I don't think it matters if we call them "methods" or "operations".
15:28:10 <dbooth> DBooth: I suggest we call them "operations".
15:28:50 <dbooth> JeffM: Now let's talk about the semantics.
15:29:45 <dbooth> JeffM: The issue is that WSDL currently allows overloaded operations; the question is whether we should disallow them.
15:30:18 <dbooth> Joyce: I propose that we should disallow overloading.
15:30:45 <dbooth> DBooth: I support that also.  I think it is clearer to have different names for things.
15:31:18 <dbooth> Arthur: It also may have server implications, as you must decide which method to invoke.
15:31:46 <Zakim> -??P49
15:31:56 <dbooth> __: I agree.
15:32:17 <dbooth> JeffM: It also saves us from deciding when two parameter types are different, then you can overload.
15:32:17 <adisakala> Adi: I agree that we shouldnt allow overloaded operations
15:32:25 <dbooth> s/__/Adi
15:32:33 <Zakim> +??P44
15:33:15 <dbooth> JeffM: Is anyone in favor of overloaded operations?
15:33:25 <dbooth> (Silence)
15:33:47 <dbooth> JM: THe sentiment of this group is to disallow overloaded operations.
15:34:06 <dbooth> __: Can someone summarize what is the problem of overloading?
15:34:27 <Marsh> s/__/Kevin
15:34:33 <JacekK> Jonathan, sorry, I gotta drop out now...
15:34:37 <Zakim> -JacekK
15:34:42 <Marsh> OK, thanks
15:34:50 <dbooth> JeffM: One problem is that you must decide whether parameter types are different, and therefore the two operations can be overloaded.
15:35:16 <dbooth> ... (Couldn't keep up with typing the other reasons)
15:36:38 <dbooth> ... Another problem is that it makes the mapping to language methods more difficult.  YOu might need to do somethign like name mangling (from C++).
15:38:06 <dbooth> Kevin: Sounds fine with me to take the feature out, but since it was in WSDL 1.1, we should document the reasons for dropping it.
15:38:23 <dbooth> ACTION: JeffM to write up rationale for dropping operation overloading.
15:39:26 <dbooth> JM: Another issue is whether one-way operations can return "false" or not.
15:39:51 <dbooth> JeffS: It seems that people were asking maybe for a new kind of message exchange pattern.
15:40:09 <dbooth> JM: WSDL 1.1 is pretty clear that a one-way doesn't have a fault.
15:40:26 <dbooth> s/false/fault/
15:41:33 <dbooth> JeffM: Where would the fault go?  
15:42:26 <dbooth> JeffS: We're talking about adding a different MEP, not changing one-way, but adding a new MEP that has an input, no output, and a fault.
15:43:49 <dbooth> DBooth: It also raises the question of whether faults should be treated separately from outputs.
15:44:16 <adisakala> Adi: Then in that case dont we need to consider faults on Notification operation which has only output message
15:44:42 <dbooth> Sanjiva: Can you clarify what kind of fault you mean?
15:45:18 <dbooth> ... i.e, app level or middleware level faults?
15:45:43 <dbooth> ... But if you don't get a fault, then it means your operation succeeded.
15:45:56 <dbooth> ... So it isn't one-way, it's two-way with an empty output.
15:46:13 <dbooth> Prasad: It's an app level thing.
15:46:30 <dbooth> ... It depends on your framework.
15:46:40 <dbooth> Keith: How would this be handled over HTTP?
15:46:55 <dbooth> Prasad: I guess it woudl be a Soap fault.
15:47:35 <dbooth> Keith: Because typically you get a 202 now, i.e., "accepted", which makes sense.
15:47:49 <dbooth> ... because the incoming msg will be processed.
15:47:56 <jeffsch> re: dbooth comment, will our abstract model clarify the relationship between the response and faults?
15:48:10 <dbooth> Prasad: The problem with the current approach is that you get either a 200 ok or you get a fault.
15:48:54 <dbooth> Keith: But that means I need to do the business processing to decide whether to return a 202 or a 500.
15:49:54 <dbooth> Prasad: This is a common business need.  You want to know if something went wrong, but you don't need to hear back anything if all is ok.
15:50:21 <dbooth> Adi: Why do we need another message pattern?
15:51:03 <dbooth> DBooth: Would there be a problem if the client gets back a message saying that all is ok, and ignores it?
15:51:27 <dbooth> Prasad: But I don't want to get back too many "ok" responses that I must ignore.
15:52:22 <adisakala> Jeffery
15:52:27 <dbooth> JeffS: It sounds like you want a "Nack" model (negative ack).
15:52:35 <jeffsch> (thanks david)
15:53:36 <dbooth> Adi: If we consider this case, then we also need to consider it for the Notification case.
15:54:12 <dbooth> JeffM: Can't one-way's return faults?
15:54:24 <dbooth> Prasad: No, that's why we're talking about it.
15:55:50 <dbooth> JM: Suppose I have a subscripion svc, and a new satellite image is pushed to me every 3 hours.  And if the data is not available, should I get a fault instead?
15:56:29 <Zakim> -K.Ballinger
15:56:46 <dbooth> DBooth: It seems like the question is whether faults are needed at all for app level issues.
15:57:38 <dbooth> JM: It sounds like we have a better understanding of the issue.  Let's continue the discussion on email.
15:58:56 <dbooth> ... I suggest that we close the current issue, and have Prasad open a new issue re-titled "Negative Acknowledgement"
15:59:08 <dbooth> Prasad: Let's just rename it.
16:00:06 <dbooth> ACTION: Prasad, JeffS close the current issue, and have Prasad open a new issue re-titled "Negative Acknowledgement"
16:00:36 <Zakim> -S.Searingen
16:00:45 <dbooth> GlenD: Are MEP's hard coded in the spec, or can they be extended through extensibility.
16:00:54 <dbooth> JeffS: Hard coded.
16:01:47 <dbooth> DBooth: If they are extensible then you're getting into the topic of workflow.
16:02:54 <dbooth> ACTION: GlenD to post email adding an issue: Are MEP's hard coded in the spec, or can they be extended through extensibility?
16:03:25 <Philippe> Glenn: SOAP include a MEP and I'd like to be able express it in WSDL
16:03:39 <Philippe> Sanjiva: use the extensibility mechanism then
16:03:44 <dbooth> Kevin: I notice we have two issue lists.  Sanjiva's and Jean-Jaque's.  Are they synced?
16:04:18 <dbooth> JM: No.
16:06:51 <dbooth> Philippe: Is MEP an architecture issue?  Soap defines one, and we define one also.
16:07:08 <dbooth> ... So should it go to the ARch group?
16:07:31 <dbooth> JM: We need to clarify the issue first.
16:07:47 <dbooth> Topic: Extensibility Proposal
16:08:04 <Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0149.html
16:08:05 <roberto> http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0149.html
16:10:34 <dbooth> Roberto: My proposal was an adaptation of a previous one.  It is separated from the "annotations" proposal.
16:10:59 <dbooth> ... For annotations there should be a very simple processing model.  The hard thing to design is language extensions.
16:11:25 <dbooth> Igor: I was trying to look at two of the proposals.  The difference seems to be the ability to include somethign from an arbitrary namespace.
16:11:42 <dbooth> Roberto: There are a couple of differences.
16:12:01 <dbooth> .. I got rid of the architected extensions.
16:12:16 <dbooth> JM: SO you'd have to have a WSDL required or WSDL extension element.
16:12:23 <dbooth> Roberto: Not necessarily.
16:13:38 <dbooth> JM: So if I start reading a WSDL doc I can tell when i reach the extension mark whether this doc will have some third-party binding info.
16:13:55 <dbooth> Roberto: Right, for anythign optional, you can't tell it beforehand.
16:14:13 <dbooth> JM: And the other difference was the mechanism for indicating what was required.
16:14:56 <dbooth> ... We need to define the inheritance of what's "required".
16:15:36 <dbooth> JM: Two key difference: (1) I can't tell from looking at the first part of the doc whether there is an extension that may be required.
16:17:13 <dbooth> Roberto: The difference is basically at the top element.  
16:18:15 <dbooth> JM: Any other opinions about whether we need both WSDL required and a top level element?
16:19:19 <dbooth> JeffS: It feels like the extra WSDL extension that you're defining is really about the architected extension.
16:19:49 <dbooth> ... I lost the motivation for the more sophisticated mechanism.
16:20:02 <dbooth> ... I clearly understand allowing any/lax.
16:20:12 <dbooth> ... But i'm missing the motivation for the WSDL:Extension.
16:20:47 <dbooth> Roberto: A language can require on a processor the use of rules that are global. The processor may need to know beforehand.
16:20:59 <dbooth> ... To avoid backtracking during processing.
16:21:11 <dbooth> JeffS: To allow a one-pass processing model?
16:21:42 <dbooth> Roberto: If you're defining an extension, then you don't want to have to label every occurrence as "required".
16:22:32 <dbooth> JM: It seems like the extension element is more convenient.  But do you still need the "required" attribute?
16:22:42 <dbooth> Sanjiva: It's nice to have the info up front.
16:23:19 <jeffsch> (Thanks Roberto)
16:23:32 <dbooth> Roberto: If we get rid of the "reqiured" attribute, then suppose I want an optional extension that has a global attribute.  How would I do it?
16:24:08 <adisakala> Adi: Sorry for informing late. I got to leave alittle early today.
16:24:14 <adisakala> adisakala has left #ws-desc
16:24:25 <Zakim> -A.Sakala
16:25:58 <dbooth> JM: It sounds like we should merge my proposal and Roberto's by removing the clause 5.d.
16:26:29 <dbooth> ... ANd in my schema we would call out the Soap binding namespace.
16:26:37 <dbooth> ... And we keep the required attribute also.
16:26:37 <Zakim> -??P56
16:26:48 <Zakim> -??P61
16:27:11 <dbooth> Roberto: And in section 4 of mine, it seems that we are talking about changing that to turn off required.
16:27:52 <dbooth> ... There's another point also, in section 5.c. (incorrectly called 5.b.).
16:28:40 <dbooth> ... I think if we were to write a similar clause for annotations we would write "a processor MAY...".
16:29:03 <dbooth> ... So I can be optimistic that the processor will actually do somethign with it.
16:29:32 <dbooth> ... If we have annotations along the line of the previous version, then the processor would not HAVE to do anything with it.
16:29:53 <dbooth> JM: ANd specifically processing of an annotation should not result in any different behavior for the rest of the document.
16:30:12 <dbooth> Roberto: But for optional extensions you SHOULD do something with it.
16:30:39 <dbooth> JM: SHould that go into the spec?
16:30:44 <dbooth> Roberto: Yes.
16:30:46 <Zakim> -MikeBallantyne?
16:31:46 <dbooth> JeffS: I think we can boil it down to saying whether you MUST or MUST NOT do something with it.
16:32:02 <dbooth> Roberto: Ok.
16:33:26 <dbooth> ACTION: Roberto to take another round at updating his proposal
16:33:35 <Zakim> -J.Thrasher
16:33:37 <Zakim> -GlenD
16:33:37 <Zakim> -K.Liu
16:33:37 <Zakim> -Don
16:33:38 <Zakim> -??P14
16:33:39 <Zakim> -??P18
16:33:41 <Zakim> - +1.408.406.aaaa
16:33:42 <Zakim> -??P16
16:33:43 <Zakim> - +33.2.99.87.aaff
16:33:45 <Zakim> -Steve.Lind
16:33:46 <Zakim> -A.Ryman
16:33:48 <Zakim> -Sanjiva
16:33:50 <Don> Don has left #ws-desc
16:33:50 <Zakim> -Philippe
16:33:53 <Zakim> -D.Gaertner
16:33:56 <dbooth> [Meeting adjourned]
16:33:56 <Zakim> -Igor.Sedukhin
16:33:57 <Zakim> -DavidB
16:34:00 <Zakim> -??P44
16:34:01 <Zakim> -Jonathan
16:34:03 <Zakim> -??P5
16:34:06 <Zakim> -D.Wright
16:34:07 <Zakim> - +1.716.383.aacc
16:35:32 <jeffsch> I think we can boil it down to saying whether you MUST or MUST NOT _recognize_ the extension.
16:35:56 <jeffsch> ... what to do with the extension is defined by the extension's spec.
16:36:02 <jeffsch> (bye)
17:29:37 <dbooth> rrsagent, where is log?
17:29:37 <dbooth> I'm logging.  Sorry, nothing found for 'where is log'
17:31:58 <dbooth> rrsagent, where am i?
17:31:58 <RRSAgent> See http://www.w3.org/2002/05/23-ws-desc-irc#T17-31-58
18:34:57 <Marsh> Marsh has left #ws-desc
18:35:35 <Zakim> -??P1
19:01:55 <Zakim> WS_DescWG()11:00AM has ended
19:29:52 <dbooth> dbooth has joined #ws-desc
19:32:37 <dbooth> zakim, bye
19:32:38 <Zakim> Zakim has left #ws-desc
19:32:42 <dbooth> rrsagent, bye