- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 7 Nov 2003 15:16:52 -0800
- To: <www-ws-desc@w3.org>
Web Service Description Group
Minutes, FTF meeting 3-5 November 2003
Sunnyvale, hosted by Fujitsu.
--------------------------------------------------------
Monday 3 November
--------------------------------------------------------
Present:
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Youenn Fablet Canon
Tom Jordahl Macromedia
Jacek Kopecky Systinet
Philippe Le Hégaret W3C
Amelia Lewis (phone) TIBCO
Kevin Canyang Liu SAP
Lily Liu webMethods
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Dale Moberg Cyclone Commerce
Jean-Jacques Moreau (phone) Canon
Bijan Parsia University of Maryland MIND Lab
Jeffrey Schlimmer Microsoft
Jerry Thrasher Lexmark
William Vambenepe Hewlett-Packard
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
Prasad Yendluri webMethods, Inc.
Observers:
David Martin SWSI
Scribe: Bijan
IRC: http://www.w3.org/2003/11/03-ws-desc-irc
--------------------------------------------------------
09:00 Introductions and logistics
- Assignment of scribes
Bijan Parsia (Mon AM)
Kevin Liu (Mon PM)
Paul Downey (Tue AM)
Dale Moberg (Tue PM)
Lily Liu (Wed AM)
- Agenda fine-tuning
- Reviewing parts 1 and 2 for publication
Sanjiva: Please review HTTP binding, esp.
Marsh: Review all three documents by wed, for informed vote.
- Charter extension (Jan 04 expiration date)
Sanjiva: like last call in march
Marsh: If we hit LC in march, we need another year to get through Rec.
If we miss March, then we need at least 18 months
Sanjiva: If we hit CR and PR, do we still meet every two months?
Marsh, Glen, etc.: YES! CR is a hard working time
Marsh: Continues asking people if they have products they need to sych
2.0 with. No response, so, seems like we have product cycle
slack. So maybe take that slack to do it "right" (or add goodies)
Sanjiva: I really want a March LC. Will throttle down participation round
then (or hopes to)
JeffSch: What's the status of asking for charter extensions? Is it
costly? Can we ask for time in dribs and drabs?
Phillipe & Marsh: Possible but costly for team.
[Lots of process discussion.]
Marsh: 2 month lc, then a month to deal with lc coments, then 2 month CR
(depending on then current implementation status), then a bit
before going to PR, then a month
[Scribe now transcribes JeffSch's whiteboard Gnattish chart]
LC
LC Period 2 months
Address Comments 2 months
CR
CR Period 2 months
Address Implementation Feedback 1 month
PR
AC Vote 1 month
Director Review 1 month
REC! Small tasteful party in Austraila
Errata 6 months
]
JeffSch: How much buffer?
Philippe: It's not a matter of buffer, but of deadline and how the group
works.
JeffSch: I'm just trying to set a realistic schedule, given the group, etc.
Marsh: Buffer of 3 months before PR. Plus, I think March is way
optimistic.
Sanjiva: But we can move specs separately
Marsh: I'd like to "lock down" part 1, at least internally, for a
while, then focus on other stuff. Maybe aim to lock down Parts
1 & 2 by Jan meeting, then work on bindings for March.
Sanjiva: Looks like, for the sake of charter extension, we should aim for
18 months.
Marsh: I hear JeffSch and Sanjiva saying we should *really* aim for
March, but maybe that's fatigue with process :) Is the WG willing
to set an LC deadline of...January?
WG: Stunned disbelief, fear, and trembling
Sanjiva: There's not much left in Part 1
Marsh: Scale of Part 1 has been shrinking
Glen: March is possible, perhaps, but dependant on what happens when we
dive into part 3
[Ok, replicating JeffSch chart, again, but only the date bits.]
LC 1&2:March 04 3:May 04
LC Period 2 months
Address Comments 2 months
CR Oct 04
CR Period 2 months
Address Implementation Feedback 1 month
PR Jan-Apr 05
AC Vote 1 month
Director Review 1 month
REC! Small tasteful party in Austraila Mar-Jun 05
Errata 6 months
]
Sanjiva: Process note: If we're going to make March or May, we need to
insist that WG make comments and proposals by Jan
Glen: But sometimes implementation experience of a "more settled" spec
reveals issues late in the game
[Some general agreement that WG members need to do serious review work,
preferably by the end of the year.]
Marsh: What's left to decide on [long list that the scribe had no hope
of transcribing]
[jjm: Scribe, the list included things such as features, headers,
endpointReference]
Umit: what about implemenation problems?
Sanjiva: First, I want WG members to committ to working early and second,
there's a place for the general impl issues.
Umit: I shall double my email correspondence.
[jjm: Sanjiva, MTOM may have some impact on Part 1 as well (infoset,
schemas), especially now that it's been split into a SOAP-agnostic
and a SOAP-specific part]
[Some discussion about what we can and can't split out from the "base spec"
and deal with separately.]
Philippe: Do we forsee future, post 2.0, work (e.g., additional bindings,
WSDL 2.1)?
Glen: Bindings, fine. but if we need to do 2.1, we've done something
wrong with 2.0.
Marsh: We still have, e.g., RDF bindings
Glen: How to connect descriptions to higher level semantics is really
interesting, but perhaps for a group like ours (not us?)
[Philippe, JeffSch, determined that Philippe wants to ask for 2 years (to
cover the Errata period)]
TomJ: We should put pressure our ourselves to do better. We should try
the "Macromedia way": *When* do we want a spec and work backwards.
Marsh: The Whiteboard schedule will go into the charter.
TomJ: Sure we don't want to aim for Jan for the spec?
Marsh, Glen, others: not actually possible
Sanjiva: Who plans to implemenation WSDL 2.0?
Marsh: We need to know who's going to implement *before* we get to CR.
Glen: Apache is going to be agreessive.
JacekK: Systinet(?) will
Bijan: UMD/MIND Lab intends an implemenation (fairly agressively)
RESOLVED: Prepare 24 month extension.
--------------------------------------------------------
09:20 Faults.
- Fault refs pointing to more than one message [3]
- Proposal for faults [4]; revised proposal [5]
- binding different fault details differently for same @messageRef
value) Optional name? Allow optional
/definitions/binding/operation/fault/@details to be the selector?
Waiting for a motivating use case.
[3] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0213.html
[4] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0250.html
[5] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0051.html
Marsh: I put this on since TomJ thought it could use another hour,
and perhaps Sanjiva has another proposal(?) Is there an open
issue or confusion on faults?
Sanjiva: There is one, mulitple faults and how to name them. there's no
use case.
Umit: Q about use case. What if someone wanted to have a header fault
and refer to an existing fault? With no name, you can't do it.
Sanjiva: What's a header fault?
Glen: Header fault is like a confirmation code.
[Scribe and Umit confused']
Glen: [explantation] "We should go for it"
Roberto: If we don't have the name, then the right way to refer to a
fault is by message reference and detail (unique in the context
of an operation).
Sanjiva: Now we're talking about the binding.
Roberto: No, it could be anything! RDF!
Sanjiva: In the spec, [missed by Scribe]
Glen: Our abstract conception of a fault is just an element. Can't
reasonably layer SOAP semantics on that.
Roberto: Found the bit in the spec: 2.5.1
Glen: You need unique details
Roberto: No, just the unique combination. Which operation, which message
ref, and details. And refering to faults is so rare, that it
being this hard is ok.
Sanjiva: You need to compare it with the input case, not general
components. Roberto, you make the point that fault ref is hard,
but compare with input [scribe lost]
Roberto: We should give it a name, that would go in the abstract componant
model.
Sanjiva: What's the use case?
Roberto: See above.
Sanjiva: Does anyone want to push this sort of use case?
Glen: Easier than Umit's header, is that in the soap world you can have
two messages that only differ on fault code. Need name.
Roberto: It should show up in the details
Glen: That imposes a uniqueness requirement on the details element. I'd
like to take out the details element, add a name, and let the
bindings take care of it.
TomJ: Call it detail, or call it message.
JacekK: The issue is do we want faults to carry information(?) in the
abstract model.
[Several people, Roberto, Umit, Glen, strongly agreed with JacekK's
formulation. Rather, they strongly said, Yes we want that.]
[TomJ writing, in very tiny letters on whiteboard, example of WSDL markup
for faults. Scribe attempts a transcription:
<interface>
<operation> in/out
<input messageref="A" body="x:in"/>
<output messageref="B" body="x:out"/>
<outfault name="myfautl" <---name not in spec (yet?)
messageref="B"
details="nsfaultXML"/>
</operation>
</interface>
<binding>
<soap:binding>
<operation>
<outfault name="myFault" <--attribute also under discussion, not in the spec (yet?)
messageref="B"/>
<wsoap:faultCode="s:receiver"/>
<wsoap:subcode="app:bad"/>
</outfault>
</operation>
</soap:binding>
</binding>
]
TomJ: So what happens if we "get rid of" [sanjeeva corrects, we don't
have name, yet]
JeffSch: What if details didn't show up in the abstract part?
JacekK: It seems that JeffSch is saying that faults shouldn't have...
[something]
JeffSch: For soap, at least, the information for describing faults is in
two different places, which is confusing. Two possibilities:
Consolidate the info. Or add a name.
Sanjiva: Third possibility: have details in outfault instead of binding.
TomJ: For the abstract part of the description, we have a fault. Let's
say I'm making the operation into a java sig. If I don't have
details, I need at least the name.
JeffSch: It's like the RPC programming hint.
TomJ: I want a name (or something) in the abstract part to hang my hat
on (chorus of agreement)
JeffSch: Is it ok if that name doesn't show up on the wire?
TomJ: I'd like also to have all the needed info in the abstract part.
Which connects to what goes on the wire.
Paul: Faults and messages are quite different, and binding dependent.
TomJ: (this is hard in WSDL1.1 because you need all sorts of stuff)
Add a name, keep the details and i can general langauge
interfaces, and have all the info I need in the abstract place.
I have the name, and I have a schema description of the xml
which I can use to generate the relevant type. Hey! Names on
all the faults!
Sanjiva: The anti-name: We don't need name. We don't have a use case.
The right way to refer to it was [something]
[TomJ adds a proposed name attribute to outfault (value "fault2") for
discussion. Contention twixt TomJ, Glen, and sanjive over the reality
of this new example.]
Glen: Use case: Stack trace.
Sanjiva: We've changed the question: Now details isn't unique.
[Abstract outfault details value to ns:faultxml2.]
Sanjiva: Solution is to add details to binding outfault
JeffSch: This example is code first driven. In protocol design you may
not even have a details. In writing protocol descriptions, I'm
careful to describe various *kinds* of fault. On this design,
I have to make up some stuff. 80-90% of the descriptoins I
write won't have a details.
[PaulD: agrees with JeffSch]
TomJ: Names help JeffSch!
Sanjiva: Another solution, move details down to the binding.
JacekK: In reply to JeffSch, we're agreed that faults carry at least
one piece of data. So generalizing it to a whole xml structure
is a good compromise. We may have one piece of xml data
associated with different faults. "Details" is the wrong name,
since it's only one piece of fault data soap (e.g.,) carries.
We want to describe *ALL* the data. So rename to "message".
Glen: We'd include in the schema a GED that does this
Roberto: I agree with Jacek. Each of these messages should have a well
defined payload. Now I'm in agreement with Sanjiva. Name doesn't
seem to simplify programming language binding.
Glen: what about JeffSch's test case?
Sanjiva: Can be handled
Glen: So you need to define a GED with no content? That's harder than
a name.
Sanjiva: If you want to add content in a binding, extend the schema
definition.
TomJ: So, my java exceptions are named by the details content
Roberto: And that's better, because you are using types, not names!
Umit: I am against taking out details form abstract and moving entirely
to binding.
TomJ: I proposed putting names in both places. Problem: If we don't
have name, then we need details in both places. My rejoiner,
we're overthinking. Names are nice to look at!
JacekK: So long as you specify that for two names, the details can be
different.
JeffSch: I would like to express my future protocol descriptions in
WSDL. Current design: I need a superflous extra GED. What if we
migrated fault codes up to interface. Say, "statusCode"
attribute on, e.g., outfault? In faults, tends to have 3 kinds
of info: Code, info string, and then a data structure (completely
dependent on recognizing the code)
Glen: Name solves that problem!
JeffSch: That could work. So long as no need for unique details, etc.
Glen: +1
JeffSch: Hey! This will work great!
[PaulD: +1]
Glen: If we add a name, so you can use codes to differeniate exception
types, and don't require details or unique details, we have
everything we need for determining the faults "type".
JacekK: How would this work with SOAP? To which code or subcode do you map
to?
JeffSch, Glen: In the binding.
TomJ: JeffSch reproposed my proposal.
Sanjiva: I'm more comfortable with "code" or "statusCode" than "name"
[Discussion arising out of details of name vs. code, diving down into
implication for mapping to programming languages. TomJ vs. Sanjiva,
essentially.]
TomJ: Concedes a problem about how to constrain name (e.g., unique where?)
correctly.
Roberto: Current uniqueness is msgref+details, we should now have unique
msgref+name within operation.
Sanjiva: Two faults in two different operations can have the same name, when
langauge binding you end up with two different things.
PaulD: Hoist faults up to the top level of interface
Sanjiva: Is the proposal that we change the componant model.
Glen, TomJ: yes, but this solves the problem
Glen: We have a lits of faults, so uniqueness is handled, and all the
operations can use them. I propose that someone write up the
proposal, e.g., Paul.
PaulD: takes on the proposal job.
JeffSch: why doesn't name or code as a child of interface, operation,
outfault do this job.
Glen: Referring to the same fault type in different operations is difficult.
This lets the model explicitly *Say* that they are the same fault,
instead of relying on the processer to figure this out.
[scribe will transcribe TomJs poster:
<interface>
<fault name="f1"
details="x:myfault"/>
<operation...>
<input>
<output>
<faults name="f1"
messageReference="B"/>
<outfault name="f2"
messageReference="B"/>
...
]
[Discussion of infault and outfault to bring Glen up to speed..]
TomJ: Putting i, n and o, u, t into wsdl is the least of our confusions.
Summarizes: Tom & others wanted names on faults. JeffSch agreed
but maybe with different name, e.g., code. Sanjiva brought up bugs
Paul brilliantly suggests hoisting the faults.
JeffSch: Point of optimization of syntax: I've expressed a pointer between
an input or output and a fault, why not embedd?
Glen: You can't.
JeffSch: Details optional?
TomJ & Glen: why not?
Glen: Do it!
JeffSch: Summarizes the proposal as applied to his use case
Umit: JeffSch, is your problem that now the abstract level is now looking
like or too the binding? Actually the other way round: binding
leaking up to the abstract level.
TomJ: Faults weren't right in 1.1. I want them easier to implement in 2.0.
It worries me that Sanjiva is on the "wrong" side from me.
Sanjiva: The only thing worrying me at the moment is that it makes faults
first class citizens.
PaulD: That's a plus to me
Sanjiva: If you look at a programming langauge design, you don't separate
them. We need to work through the details, and we're trying to
publish.
Marsh: It doesn't sound like faults is ready, especially as we have a
fairly extreme redesign.
TomJ: Ok, can we live with the problems of either less rad examples?
Umit: TomJ, you never answered Sanjiva, why can't you live with
details/message as a wrapper?
Glen: We want to say what type the fault is without having to have
anything show up on the wire.
Roberto: But that's different from the wildly praised radical direction,
fault is like a GED schema thingy
Glen: Rebuts with soapy arguments.
Sanjiva: JeffSch made a good point about the "three things" of a fault.
Details was intended to cover the payload part, but we don't have
anything for the fault code part. I think it's fine to add that
[Discussion of Roberto's "it's a rename of xs:element" point, with Glen and
JacekK objecting, Sanjiva, Roberto and Umit insisting.]
JacekK: We want to be able to say, for code, exactly what goes on the
wire. There must be something *set* for a fault and it must be
something outside of the xml schema.
Sanjiva: I think JacekK agrees with me.
JacekK: Yes
Sanjiva: Code and details should be distinct. Abstractly, that looks good
and nicely general. Bonus: it maps nicely to SOAP (though we need
not be bound by being nice to map to SOAP.)
Glen: If I have two different operations with same fault ref, then in
my soap binding I have two places where I potentailly have to bind
something, so I have to make them match and express them in both
places.
Roberto: Not necessarily. Context will help
Glen: I need to bind "that" name to a heirachy of soap codes. Don't want
that at the abstract layer, but in the soap binding. I need to
repeat the info and check the bindings. The Top Level approach
solves this problem.
Roberto: Prefer to solve this with a binding shorthand
Glen: That would work, but PaulD's solution is cleaner. It's not code,
but it's a name.
Sanjiva: We add a name attribute to infault and outfault in abstract
operations, make details optional. Inside binding we add infault
and outfault and inside them we use the same keys to reference back.
Separate discussion about simplifying the binding syntax. (Here
ends Sanjiva's proposal)
TomJ: We don't have in/outfault in bindings?
Sanjiva: No, but we need it
TomJ: So we're going to add it.
Marsh: Yes
[JeffSch, editing above stuff in real time, projected:
<interface>
<operation ...>
<input messageRef='xs:NCName'
body='xs:QName'
... />
<outfault name='xs:NCName'
// maps to binding/operation/outfault/@name
messageRef='xs:NCName'
// maps to interface/operation/input/@messageRef
detail='xs:QName'?
// probably rename]
/>
</operation>
</interface>
<binding>
<operation>
<outfault name='xs:NCName'>
<wsoap:Code>
<wsoap:Value>xs:QName</wsoap:Value>
<wsoap:Subcode>
<wsoap:Value>xs:QName</wsoap:Value>
</wsoap:Subcode>
</wsoap:Code>
</outfault>
</operation>
</binding>
]
[Looking at the soap binding part. Some discussion about the need
for subcodes and subsubcode.]s
Sanjiva: Syntax easily supports it so why not.
Roberto: Need a msgref on outfault as well (in binding).
[So, name & messageRef on binding/operation/outfault.]
TomJ: I have concerns with this messageRef thingy.
Sanjiva: messageRefs maps to field in pattern.
JeffSch: Describes the fast typing person enacting a web service (fast
reader, as she has some wsdl printed out beside her)
messageRef (on fault) indicates which message the fault replaces.
Glen: It's more common that you're going to have a sit where one
messageRef with several different fault names, than the reverse.
TomJ: What are we hashing out?
JeffSch: Didn't understand the proposal. want to get some concrete syntax
up there to bring us all on the same page
Glen: The difference between the proposals, PaulD's, you can use only
the name of the fault, you can take the name and bind it in a
particular way. In the other proposal, it's trickier and that's
why you need lots of messageRefs
JacekK: If we go with the PaulD proposals, would the binding specify just
one binding for the fault? Then we don't need the messageRef
attribute in the binding.
Glen: Instead of first class faults, we leave them in the operations
and make them scoped to the entire interface. and the names may
be reused after first declaration. Why would you want to bind
somethign differently if in or out? Isn't it just a message?
PaulD: It's just information that something's gone wrong. You don't
care where it's coming from.
TomJ: We're losing the focus my standing up brought. We've had this
conversation twice.
Umit & Scribe: Three time!
Sanjiva: If hoisting is right, we should do it even if it's a big change.
My intuition is that hoisting isn't done that way in programming
languages.
Glen, TomJ, Bijan: Wait, it is done that way.
[Dicussion between Sanjiva and Glen; Glen is again accused of
soapcentricity.]
TomJ: It's still valid to talk about faults as distinct from
input/output messages. Seems like Umit & Roberto are wanting to
go back on that distinction.
Roberto: This feels like the message discussion all over again.
JeffSch: The reason we are in this design trough is due to the requirement
that if a fault occurs in >1 operations, map to the same exception
type. With requirement, we go toward PaulD's proposal. Otherwise,
otherwise.
Glen: +1
Sanjiva: The requiremnt is a programming model issue.
Glen: No, it's also a wsdl writing issue. More times to repeat, the
more times it can screw up.
[PaulD: Duplication too - it's a many (interface/operation/message) to many
(binding/operation/message) relationship]
Sanjiva: Ok, redundant info reduction fine. but the other requirement is
still a lang binding issue
Glen: Can we go faults within operation syntax & if it's used twice,
then it's the same thing.
Sanjiva: If you use the same name, then the details must be the same.
TomJ: You can define a fault with a name + some payload, and that fault
can be in or out. And refs to message A, B, C, D, etc.
[Scribe misses some subtle weirdness binding thing that Roberto's raised
and Glen tries to squash.]
[Roberto: You could have two <infault/> in the same operation for different
message references.]
JeffSch points to requirement: Allow fault to occur in both an infault and
an outfault.
JeffSch: That's sufficent to generate Roberto's cases. You replicate the
interface structure in the binding, then you decorate, with
arbitrary fine detail
Glen: (after some JeffSch & PaulD driven discussion + Roberto) we're
80% of the way to a proposal!
[Lots of discussion with people being pretty happy with the state of things.]
Glen: But codeDefault must be worked out. Add to binding
wsoap:FaultDefault name = 'xs:NCName"><wsoap:Code>...</wsoap:Code>...
JeffSch: We are able to drill down in soap binding to specific messages
to specific stuff
Sanjiva: We don't have these any more
Glen & Umit: So does that mean the wg doesn't want to support SOAP 1.2 RPC?
[General clamor to defer that discussion.]
[JeffSch adds the details of various proposals to his document, which will be
forwarded to the scribe for sharing purposes.]
Sanjiva: Lets get enough together to take some sort of vote
PaulD: I'm not sure my proposal is worked out enough to face a vote
Glen: My question: if you can override what faultdefault says, are you
diluting the value of the reason you put it there in the first
place?
[Exchange between Glen and JeffSch following up on Glen's question.
Discussion resolves to "that's not so bad" from Glen, JeffSch, and TomJ.
(if only scribe understood what it was that wasn't so bad).]
JeffSch: Stuff about subcode expressed in a code that Glen understands
but scribe doesn't.
[TomJ: Tom thinks that being able to override the faultDefault isn't so
good for implementations (disagreeing with the 'not so bad' feeling)]
TomJ: Don't override faultdefault
Sanjiva: So faultdefault is just fault
TomJ: Yes!
Glen: This argument goes back over to MEP. If you use the same thing
in differnt places to mean differnt things its not the same
thing so you should give a different name.
[Scribe notes that it seems that the "universal argument" seems to have
been discovered. Everyone claims that the same argument is good against
everything.]
Marsh: Can we go with a default with overrides for now?
[Lots of violent discussion. No one's proposed going back to 1.1.]
TomJ: Ok, we can life with faultdefault *for now*
Glen: Does anyone other than PaulD, me, and maybe TomJ have interest
in PaulD's proposal and developing it?
TomJ: I like the idea but I'm also in favor of finishing the spec more.
The Standard Rant about How the Group Embracing Radical Changes
Except When He Likes It
Sanjiva: Should we adopt the incremental change and then work on the
radical one *for the sake of publication"
Marsh: Ibid.
TomJ: Yes! That's my original proposal anyway.
JeffSch: Labels the three proposals in his doc
Marsh: I was merging 1 and 2
Glen: I don't want 1 without 2
[Note that everywhere you see messageref == messageReference]
Marsh: Proposal 1: Adding name to faults...[scribe has no hope]
JeffSch: Stuff marked in red in my document
DBooth: Trying to get clarity on what we're deciding
TomJ: Are we embedding all the wsoap:FaultDefault, etc.
[Scribe clarifies: Proposal 1 is clearly marked in JeffSch's document which
will be included in the minutes.
See http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0025.html
<interface ... >
<operation ...>
<input messageReference='xs:NCName' // maps to field in pattern
body='xs:QName'
... />
<outfault name='xs:NCName'
// target for binding/operation/outfault/@name
// if used twice, means the same fault
messageReference='xs:NCName'
// maps to interface/operation/{input,output}/@messageRef
// may match other faults in interface w/ same @name
detail='xs:QName'?
// must match other faults in interface w/ same @name
... />
</operation>
</interface>
<binding ... >
<wsoap:FaultDefault name='xs:NCName' >
// rollup like other operation-specific information
// good for all instances of @name
// explicitly does not include @messageRef
<wsoap:Code> ... </wsoap:Code>
</wsoap:FaultDefault>
<operation ... >
<outfault name='xs:NCName'
messageReference='xs:NCName'
// required because same @name can occur within an
// interface/operation with different @messageRef
>
// overrides binding/wsoap:FaultDefault with same @name
<wsoap:Code>
<wsoap:Value>xs:QName</wsoap:Value>
<wsoap:Subcode>
<wsoap:Value>xs:QName</wsoap:Value>
<wsoap:Subcode> ... </wsoap:Subcode>
</wsoap:Subcode>
</wsoap:Code>
// Detail is just interface/operation/outfault/@detail
</outfault>
</operation>
</binding>
]
Sanjiva: I'm fine with body for now, but want to revisit during the headers
discussion.
TomJ: I like detail
Glen: Given the @name, the names of the rest isn't as critical
TomJ: My objection: detail carries *good* baggage for soap people
JeffSch: Can no one live with detail?
Marsh: So, we're sticking for detail.
APPROVED: Proposal 1 (see JeffSch's document)
ACTION: PaulD to work out his proposal in more detail
Marsh: Rearranging the agenda for the sake of moving the Patterns
discussion to tomorrow for the sake of the remote folks
--------------------------------------------------------
12:30 Lunch
--------------------------------------------------------
Scribe: Kevin
13:30 RPC-style rules
- Syncing rules with SOAP 1.2 RPC [8]
- Clearer statement of normativity [9,10]
[8] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0059.html
[9] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0057.html
[10] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0062.html
Current status: Sanjiva has put a marker in the ED of part 1, Umit has
sUmitted issues and proposals.
[Sanjiva: http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0007.html]
Looking into the current spec section 2.3.1.1
[TomJ: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl20.html#InterfaceOperationStyle]
DBooth: Should not talk about what the WSDL processors do or not do,
should only focus on what wsdl documents are or are not.
Specification implies what the services it interacts must do.
JeffM: Schema defines what the message needs to look like on the
wire.
[Second part of Oracle proposal is related to schema. More discussion
on if the second paragraph in the above section is right.]
Jeff, Sanjiva, Umit: we need to be clear about is schema is conformant
to what's specified in the RPC style.
Jaccek: Has a proposal for rephrasing the sentence
[JacekK: http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0026.html]
Jaccek: It's the reader to follow the rules if the style has a value.
[JacekK: If the {style} property has a value, it implies the rules that
were used to define the properties of that operation component.]
Sanjiva: Should be "the rules must have been followed" (by the writer?)
[JacekK: If the {style} property has a value and the properties of the
operation component do not follow the rules specified by the
style property, the WSDL is in error]
JeffM: We don't have a model for WSDL processors.
[Roberto: "It is an error if the {style} property has a value and the
rules associated to it have not been followed"]
[Let's say if a schema doesn't follow the rpc rules, it's an error.]
DBooth: Two things. a) schema must be conformant to the rules,
b) a message must be conformant to the rules
[DBooth explain his digram in the whiteboard: wsdl spec defines the wsdl
definitions which in turn defines the behavior of the services
and conformances of message.
Sanjiva: We agree the rules must be followed in defining the schema,
those that not follow are errors.
Jaccek: Points out maybe it's more than schema conformance.
Marsh: Concerned it's sort of circluar (missed what's the it?)
[Sanjiva: Note that the property MAY not have any value. If this property
has a given value, then the rules implied by that value (URI)
MUST be followed or it is an error.]
[Marsh: JeffM: Messages MUST conform to the schema.]
[DBooth: ACTION: JeffM to propose text to the effect that messages must
conform to their schemas.]
Sanjiva: Will reword the first paragraph
[PaulD: Concerned that message may legitimately contain *more*
information than defined in the schema, Glen cited encryption ..]
Marsh: Looks like we will delete the second paragraph.
Jeff: If the style has a value for rpc and the schema doesn't follow
the rules, the document is considered not conformant
[now looking into the rpc style rules]
Umit: Made rewordings suggestion in emails
[group compares the suggestions and the current ED draft. Umit's proposal
is at http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0007.html]
DBooth: why do we need to say a child elements may contain nillable,
minoccurs, etc
JacekK, DBooth: it's really not a rule
[Philippe: s/xsi:Nillable/nillable/]
ACTION: Sanjiva make a clarification "note that" kind of text to replace
the third bullet points in rpc rules
[fourth bullet: must all --> MUST both. (scribe may messed up the bullet
numbers. the above is for the sentence "Input and output elements MUST
all be in the same namespace")]
[next rule: The complex type that defines the body of an input or an output
element MUST NOT contain any attributes. Clarification : "third bullet" is
"The child elements MAY contain the following attributes: xsi:Nillable,
minOccurs and maxOccurs."]
[Roberto writes on the white board exploring how the "same namespace" rule
works in case one interface inherites another.]
[next rule: The complex type that defines the body of an input or an output
element MUST NOT contain any attributes (accepted)]
[next rule: If an element that appears as a child of an input element also
appears as a child of an output element, it MUST be declared by
using the same type. (group is ok with the above rule).
Jaccek: need one more rule
[JacekK: The input|output sequence MUST NOT contain multiple children
element declarations with the same name]
[Sanjiva: <item><p> If elements with the same qualified name appear
as children of both the input and output elements, then
it MUST be declared by using the same type.</p></item>]
[Now move on to rules after the paragraph "Furhermore, the following rules
MAY BE used to map between a message and a signature of a remote procedure
call. These rules are suggested conventions to accomodate mapping."]
[rule: If an element is a child of the input element and an element
with the same name is not a child of the output element, then it
represents an input parameter.]
[Need wordsmithing.]
[rule: The parameter order is specified by using the parameterOrder attribute.
Sanjiva: parameterorder is out of the spec
[Roberto: http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0347.html]
Umit: If we don't say anything about parameter order, the spec is not complete
TomJ: What's the problem?
Umit, JacekK: without parameter order, one can not tell the return value
reberto explains his proposal expressed in the url above
[JacekK: counterproposal: parameterOrder contains *ALL* parameters (excl.
return value) using a list of QNames; if parameterOrder is missing, parameter
order and return value is unspecified]
JacekK: signature should be Qname
Roberto: it's qname
JacekK: the structure is complicate
Sanjiva: the signature thing has nothing to do with what's on the wire. Likes
the proposal.
(missed Sanjiva's concern)
TomJ & Umit: two problems need to be resolved: order and return value
[more discussions about the proposal. scribe fails to capture the minutes]
JacekK: A non-signature comment. if it's a one way, the rules will break.
the rules could say we have to use one of the two meps: in-out and
in.
[PaulD: now we've accepted we are going to have IDL in/inout/out etc. Likes
Roberto's syntax as it can can handle multiple returns and could be
easily added to in the future without breaking the comp-model]
JacekK: it's a principle in W3C that microstructure inside a simple type
is considered no good
[more discussion on the use of xsd]
[JacekK:
<input ...>
<sequence>
<input>a</input>
<output>b</output>
<result>c</result>
</sequence>
</input>
]
JacekK: This is Roberto proposal amended
Roberto: The use of ## in my proposal is what XSD use for wildcards
[PaulD: looks forward to Savas and Mark Baker's reaction to this ..]
JeffSch: Let's treat Roberto proposal as status quo and ask those who have
issues for improvement.
Marsh: Is it possible to have two styles for rpc?
[(one of the two styles can define the parameter order stuff). look into
that later. Discussions on multiple return values.]
PaulD: Would like to add constraints to Roberto proposal not allowing
re-ordering parameters.
Roberto: The following needs to go to the spec under RPC style:
The spec for the rpc:signature extension would state all the usual
requirements (all parameters MUST appear, all in parameters MUST
be present in the input message and MUST NOT be in the output, etc.).
Marsh: Any objection to adopt Roberto proposal?
[hear no objection. we adopt the proposal]
[Prasad: Please note the optional / hint nature of all this. Just trying to
make sure that aspect does not fall through the cracks.]
ACTION: Sanjiva to put note in spec to reflect the decision of adopting
Roberto proposal
15:00 Break
--------------------------------------------------------
15:20 Update from David O on TAG progress on WSDL Component Designators
David: The group asked the TAG about the use of fragement identifier
in namespace URI. The answer from TAG is Yes. TAG raised a
new issue (issue 40). TAG considers frag id as a good idea.
There were discussions on use dot separator.
ACITON: Marsh put in future agenda for discussion on TAG feedback on
frag id
[Philippe: TAG (draft) finding: http://www.w3.org/2001/tag/doc/abstractComponentRefs-20031030]
Sanjiva: Concern on fragid approach: it's only defined with mediatype.
[Philippe: RFC2396bis: http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html
fragment identifiers:
http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#fragment]
--------------------------------------------------------
15:45 Uniqueness on the wire
- Proposal from Umit [11]
[11] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0112.html
Marsh: Summarizes two sides of the discussions: jeffM indicate that WS-I
has required the message must be unique in the wire; JeffSch doesn't
see it necessary.
[Umit's proposal is at http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0112.html.]
Marsh, Umit: the core of the issue is dispatching the message to the right operation
[Umit: http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0121.html]
Sanjiva: Needs to understand the problem better: the service provider knows
the message it's expecting and know how to dispatch it
[Umit, DBooth, Glen give their reasonings]
TomJ: if you are the service provider and doesn't provide enough info in
WSDL, you screw up
Umit, JeffM: no
[DBooth: If a WSD has two operations, both of which are output-only, and the
message schemas are the same, then a client may have trouble
dispatching, even though the service doesn't have a problem.
Glen: Not sure if we can mandate something here
Umit: There should be a standard way to distinguish messages
DBooth: We agreed to distinguish messages in wsdl, it makes sense to do the
same for the wire message.
Umit, Glen: yes
[more discussion on if headers are about infrastructure or application]
TomJ: Let's stop talking about header:)
[PaulD: An RPC over an async transport has to dispatch the response to the
client.]
[discusison back and forth if we need standard way to distinguish messages]
JacekK: A non-proposal: let's just note this issue in the spec
DBooth: Should be in the primer
[Sanjiva: +1 to primer.]
[JacekK: and note the "unique GEDs" solution as a possibility.]
Marsh: There are multiple ways to resolve this. concerned just choosing
one will limit the possibilities.
[more discussion on Glen's proposal on using feature to resolve this.]
Umit: The issue is about how to relate a message to a operation, let's
focus on it
[direction under discussion: define a required feature for dispatching. it's
an error if a wsdl/message doesn't support that feature.]
PaulD, Sanjiva: we don't have to do anything: we already have the mechanism
for one to reference a feature. one can just define a feature for
dispatching and require it in wsdl.
Glen: Maybe we need to make the feature a citizen of wsdl so we can
guarantee it will be around
Sanjiva: The proposal is that we observe in the primer this is an issue.
The way to solve it is to use feature and property. the question
now is should we define the feature.
Marsh: Primer will add simple example that enables message dispatching.
Someone need to write proposal for dispatching features using
soap action, and GED
JeffSch: Why do we need to decide on one way now while there are many
different future worlds?
Roberto: Doesn't have to be GED, will be happy if WSDL add A property
for dispatching.
[Glen, Roberto, JeffSch debate on why now]
[the group is getting tired of the repeated discussion, looking for proposals
for moving forward.]
Marsh: Seems we are rejecting Umit's original proposal of requiring GED
in all wsdl
[Roberto: http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0121.html]
Strawpoll 1. adopting the GED proposal from Umit/Roberto
for: 5, oppose 11
JeffM: How many think the requirement should be addressed some way?
strawpoll 2. each wsdl must have a required feature associated with dispatching
for 3, against 13
strawpoll 3. enable people to indicate so in normative way
for 13, against 3
Marsh: We will pursue the normative feature idea. Now we need some body
to write the features up.
ACTION: Umit (with help of Glen) will write up a proposal for normative
dispatching feature.
--------------------------------------------------------
18:00 Adjourn
Received on Friday, 7 November 2003 18:16:52 UTC