IRC log of ws-desc on 2002-05-23

Timestamps are in UTC.

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]
15:01:54 [marioj]
marioj has joined #ws-desc
15:01:57 [SteveLind]
SteveLind has joined #ws-desc
15:02:07 [Zakim]
15:02:09 [Zakim]
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]
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]
15:02:50 [Zakim]
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]
15:03:09 [Zakim]
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]
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]
15:06:29 [Zakim]
15:06:41 [Don]
Don has joined #ws-desc
15:08:26 [Zakim]
15:08:53 [youenn]
youenn has joined #ws-desc
15:09:28 [Zakim]
- +1.512.868.aabb
15:10:41 [Zakim]
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]
15:13:17 [Zakim]
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]
+ +
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]
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]
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]
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]
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]
15:32:33 [Zakim]
15:33:15 [dbooth]
JeffM: Is anyone in favor of overloaded operations?
15:33:25 [dbooth]
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]
15:34:33 [JacekK]
Jonathan, sorry, I gotta drop out now...
15:34:37 [Zakim]
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]
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]
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]
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]
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]
16:08:05 [roberto]
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]
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]
16:26:48 [Zakim]
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]
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]
16:33:37 [Zakim]
16:33:37 [Zakim]
16:33:37 [Zakim]
16:33:38 [Zakim]
16:33:39 [Zakim]
16:33:41 [Zakim]
- +1.408.406.aaaa
16:33:42 [Zakim]
16:33:43 [Zakim]
- +
16:33:45 [Zakim]
16:33:46 [Zakim]
16:33:48 [Zakim]
16:33:50 [Don]
Don has left #ws-desc
16:33:50 [Zakim]
16:33:53 [Zakim]
16:33:56 [dbooth]
[Meeting adjourned]
16:33:56 [Zakim]
16:33:57 [Zakim]
16:34:00 [Zakim]
16:34:01 [Zakim]
16:34:03 [Zakim]
16:34:06 [Zakim]
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]
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]
18:34:57 [Marsh]
Marsh has left #ws-desc
18:35:35 [Zakim]
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