- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 7 Nov 2003 15:17:48 -0800
- To: <www-ws-desc@w3.org>
Web Service Description Group
Minutes, FTF meeting 3-5 November 2003
Sunnyvale, hosted by Fujitsu.
-------------------------------------------------------
Tuesday 4 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
Arthur Ryman (phone) IBM
Jeffrey Schlimmer Microsoft
Jerry Thrasher Lexmark
Steve Tuecke Global Grid Forum
William Vambenepe Hewlett-Packard
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
Observers:
David Martin SWSI
Scribe: Paul
IRC: http://www.w3.org/2003/11/04-ws-desc-irc
-------------------------------------------------------
09:00 Pattern inference [6]
(optional @pattern, optional @messageReference):
- Tabled decision on optional @pattern to future telcon.
- Tabled decision on optional @messageReference to a future telcon.
- Sanjiva proposes dropping redundant {direction} property from
the component model [7]
[6] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0172.html
[7] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0210.html
Marsh: Quick background of subject - Sanjiva to outline proposal,
Amy & Jean-Jaques to reply
Sanjiva: Status quo syntax for operations, user has to remember pattern
uris (complicated), value for messageReference - not orthogonal,
only not user settable
Marsh: Two issues: could come up with better labels, and make it
optional.
[Marsh: http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0344.html]
Sanjiva: Rename input and output are redundant
Roberto: So long as you understand the pattern
Sanjiva: Outlines the proposed new rules to derive optional values
[jjm: http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0013.html]
[alewis: Amy's alternative proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0017.html]
jjm: Remembering uri not a problem, easy to remember - basically the
same for many patterns.
Paul: Why not have the name of the message in the pattern tags?
Amy: Specifies single rule: one way messages can have a short-cut -
only for unambiguous MEPs
DBooth: jjm's if you do not know the MEP you would not know the
direction of the messages being passed
Tom: +1 to Amy's proposal
Marsh: Amy's proposal has extensibility point for URI for a pattern ..
Sanjiva's extension would be an error ?
Sanjiva: Combine best of both: we should adopt Amy's proposal as his
proposal builds on it. URI can override the default rule
jjm: Why is important to keep the direction of the message ?
JeffSch: Firewalls and other intermediaries
Amy: May be better off using the words "input" and "output" rather
than A, B, Request, Response, etc
Sanjiva: "input" "output" seems natural now, but may seem strange in the
future.
DBooth: Name could be used as a heuristic, "inputXXXX" "outputYYYY"
Sanjiva, JeffSch: some problems with jjm's proposal, element names can't
be in the WSDL namespace
DBooth: Let's decide on Amy's proposal
[DBooth: Amy's proposal:
Proposed syntactic changes:
- Make
interface/operation/(input|output|infault|outfault)/@messageReference
optional (this was one of Sanjiva's proposals)
- Introduce the following rule:
When a pattern contains only one message in a given direction,
then the messageReference attribute is optional. When a pattern
contains more than one message in a given direction, then the
messageReference attribute is required (to disambiguate which
message is defined by the element).
]
JeffSch: Let's come up with some text for this
Marsh: straw poll
[Straw poll: Make the messageReference optional if there is only one message
in the MEP (Amy's Proposal) ]
youenn: Use schema to validate rather than infer the valid patterns. I
would like to study each pattern, write a schema extract and use
it to validate each operation, default value, missing messages etc.
Marsh: Is there enough value in writing schema extracts just to support
WSDL validators ?
[DBooth: DBooth's generalization of Amy's proposal: If the MEP has no more
than one message in each direction, then the messageReference
attribute for each message is optional, because it can be deduced
from the pattern. ]
[alewis: Agreed. That was what I intended to say. Actually, that's what I
thought that I said.]
Scribe: Clarification of wording ...
Amy: DBooth has presented well my original intention.
[DBooth: Generalization 2: If the MEP has only one message in a given
direction, then the messageReference attribute for the message in
that direction is optional, because it can be deduced from the
pattern. ]
[alewis: I can agree with that extension, though, because it makes sense to
me, too.]
Sanjiva: confusion reigns ..
[alewis: Examples:
1 input: always does not require @messageReference
1 input, 1 output: always does not require @messageReference
2 inputs, 1 output: inputs *require* @messageReference.
In my original proposal (as intended), output also required it. In the
modified proposal, does not.]
TomJ: Wants simple rules!
Roberto: And what about faults ?
DBooth: This doesn't address faults
Amy: Would like to see the outcome of yesterday's discussion before
covering faults in my proposal.
Sanjiva, TomJ: use similar simple rule for fault.
[DBooth: Fault wording: If the MEP permits only one fault in a given
direction, then the messageReference attribute for the fault in
that direction is optional, because it can be deduced from the
pattern.]
JeffSch: doesn't that bake-in FRM ?
Sanjiva: this wording isn't enough
[alewis: JeffSch: No, it doesn't bake FRM in. The fault wording counts the
places where faults can occur, and allows WSDL authors to use the
same shortcuts.]
[DBooth: New wording: If the MEP (including its fault rule) permits only one
fault in a given direction, then the messageReference attribute for
the fault in that direction is optional, because it can be deduced
from the pattern.]
[alewis: FRM: fault replaces message. MTF: message triggers fault]
Sanjiva: We're talking about deriving the inferend default value for
messageReference.
Roberto: I don't like it, there is an order requirement / significance.
Sanjiva: XML has a document order concept
Amy: You have to look at the child element, sounds unnecessary complex.
URI isn't too difficult.
jjm: +1
[Roberto: +1]
[youenn: +1]
Sanjiva: It's going to be an extra burden to someone used to writing WSDL 1.1
Amy: Pattern URI saves a child element traversal
TomJ: It's not going to be that bad!
Amy: It's syntactic sugar, tools won't care or have any significant burden
Roberto: +1 to Amy
youenn: XML default for this attribute
[TomJ: So if the tools don't care, then we should do this because it is
for the human reader/writer.
pauld: +1 to youenn
Umit: syntactic sugar should be more explicit
jjm: This makes WSDL more complex, the URI rules have to be learned,
and extra burden to users
pauld: +1 to jjm
Sanjiva: These patterns are going to be very common and maybe written by
hand, so should be as simple as possible.
[alewis: I do not agree, and I *do* write all my WSDL by hand. And read
other people's WSDL. And *really* *really* want to *always* see
the nice @pattern uri, because it's unambiguous altogether.]
Glen: I want something to happen here, and now!
Straw poll: Should we make the pattern attribute optional in some fashion?
8 for, 10 against
Marsh: Status quo reigns as for now ..
Sanjiva: This issue is important to IBM.
Marsh: Anything else on patterns? no, so take a break!
[alewis: David: we probably need action items for someone to write up the
@messageReference optionally. You had some good text for that, I
thought.]
[DBooth: Amy, good idea. Please steal my text. :) ]
[JeffSch: FYI, I added the appropriate editorial for optional @messageReference.]
-------------------------------------------------------
10:30 Break
10:50 Features and Properties
- Glen's Features and Properties musings [21]
- Arthur's proposal to unify property URIs and QName URIs. [22]
Alternatives include using property markup, or a QNamed
attribute.
- Issue 2: SOAPAction has been deprecated, as of SOAP 1.2 [23].
[21] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0144.html
[22] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0047.html
[23] http://tinyurl.com/mwuy#x2
Marsh: Inline schemas postponed (until tomorrow, if time), May cover
header item in this discussion.
Glen: Outlines his overview document.
[Roberto: http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0144.html]
Glen: New pattern from SOAP 1.2 not yet widely used but has great promise.
WS-Reliable-Messaging as a worked example.
Marsh: How do we evangelise this pattern in our spec?
Glen: Properties can be set and used generically, or may be tailored to
a given higher-level spec.
Umit: How do we know how WSDL and an external spec are tied together ?
Glen: It's the well known URI
Umit: By referencing an external spec WSDL may no longer describe the
messages exchanged.
Glen: Dips his toe into headers discussion
Umit: My question specifically was about how a feature/property would
be able to "refer" to specific WSDL definitions.
Sanjiva: Difficult to define F&P in this working group, would like to move
this into an external policy framework.
Marsh: soapAction ?
Scribe: Glen and Sanjiva discuss how generic policy is ..
JeffSch: Concerned about scope of this discussion
Glen: Acknowledges richer policy frameworks may emerge in the future ..
Roberto: May be other policy languages such as RDF, F&P is immature and
maybe should be removed from the spec.
Marsh: Maybe out of scope for this discussion.
Dale: There is a requirement that F&P answers.
Sanjiva: Open content ?
Umit: Uniqueness on the wire was going to be resolved by F&P and now
you are going to remove it ?
JeffSch: Group agreed to do something about uniqueness, push-back on F&P
is not related. other extensibility models exist.
Philippe: Maybe remove them and add them in again later if required.
Sanjiva: Concerned about wide impact F&P has on spec for something that
may not get used.
Bijan: As someone interested in layering on top of WSDL, extensibility
is good, even if we don't have a concrete worked out use now
youenn: Discusses Roberto's concerns. Features are abstract and not at
the binding level.
Roberto: SOAP 1.2 binding needs to express what SOAP 1.2 does. we need
stronger requirements here.
jacek: Postpone discussion until we can discuss policy (or whatever)
Glen: Accept they're there now and move on.
JeffM: Leave it in there. purpose is for users, not us.
JeffSch: Microsoft may consider filing a minority opinion against F&P
[Marsh and DBooth discuss where F&P would be described .. Primer ? ]
Dale: Questions who would implement what and would these URIs be
registered
Marsh: W3C is moving away from central registries. Not clear which
extensibility mechanism should be used when
Philippe: It will be simpler to remove them now than later.
Roberto: Still troubled that best (or only) use of F&P may be policy.
what is the requirement for F&P ?
Bijan: Questions Marsh about procedure, at-risk and last call ..
JeffM: Let's just move on.
Glen: Pen in hand. outlines another (non-policy) example of F&P -
a notary service.
Marsh: What more do we need in the spec to better describe F&P ? Arthur's
proposal ?
Sanjiva: Only use we have is for soapAction, so maybe a specific
attribute better than generic mechanism.
Marsh, Sanjiva: is Arthur's proposal still alive ?
Arthur: I prefer not to discuss proposal until the F&P issue has been
resolved. Glen, will you champion my proposal on my behalf.
JeffM: Let's just move on.
JeffSch: Would like to see the impact on the component model of a first
class property versus open extensibility model. Yesterday we
decided on a 1st class property for parameterOrder
Glen: Here is a spec by which you can add things generically
Sanjiva: hot food has arrived!
Marsh: let's decide quickly!
Umit: why are people against this proposal
Glen: it's not clear to me
Roberto: any elements question implementation of new WSDL propertySchema
construct. This is a big step. soapAction doesn't justify this
change.
Glen: just because we only have one or two examples now, doesn't
preclude others in the future
Straw poll: adding propertySchema in lines of Arthur's spec
4 for, 4 against
Marsh: Abstains carried the day. can we not do this ? satus quo ?
Glen: Anyone want to lie in the road
Marsh: Anyone object to dropping the proposal
[silence]
Marsh: soapAction *before* lunch
[hubbub, near revolt. Chair is undeterred :-)]
Sanjiva: Discusses syntax with Glen and JeffSch.
TomJ: I like Sanjiva's proposal (from the list).
JeffSch: Why is the WG obsessing on syntax ?
Philippe: With F&P we have a way to achieve this. this is a syntactic
short-cut
[further discussion on impact on component model]
Sanjiva: Let's vote!
JeffSch: 3 things: syntax, component model and structure and description
how component model speak about external spec, HTTP, SOAP, etc.
third part requires parlence of external spec.
Marsh: Do we care that we have two different component models for the
same thing? Maybe a canonicalisation issue in the future to address.
JeffSch: We have two parallel tracks at the moment.
Glen: Mentions possibility of another proposal
Umit: Is soapAction required ?
Glen: No
[working group have full-bladders and empty stomachs.]
Marsh: Lets tackle soapAction before lunch!
Straw poll: retain a non-generic way of representing soapAction ?
for 10, against 2
Straw poll: keep operation (versus action)
1 for, 3 against
Marsh: can we live with <wsoap:action uri="uri"> ?
[consensus for yes, pizza smell in room!]
Straw poll: URI in simple content or attribute ?
[consensus for attribute]
[stampede for lunch.]
-------------------------------------------------------
12:30 Lunch
13:30 Drop @headers
- Proposal from Sanjiva [24]
- Related questions from Youenn [25]
[24] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0107.html
[25] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0033.html
Issue: should headers be dropped from interface? Reason: headers are part of
binding.
Youenn: appeal to an application data vs other data distinction
Umit: Is a marker needed at abstract to indicate what is multiply
realized in binding?
Glen: Point is that multiple header treatments still expressible in
binding.
Youenn: Describes an image processing service with alternative
parameterizations. In some way one binding appears to use a
SOAP header to carry some image info or ref. Use case is
maybe that we don't support partitioning app data in different
parts of a binding.
Sanjiva: Presumption has been not to support that partitioning, maybe
we should
Lily: Customers make use of headers for app functions
Glen: Should we enforce app in soap body and metainformatin context
in headers?
Jeff: Not ours to set soap conventions.
JeffM: Where does wsdl allow the distinction to be drawn?
Glen: Contract on what and where data placed, not of course on
dynamically selected values.
JeffM: Wants the interface to include contract details. If f&p
endangered and we trash headers aii in interface, then what is
left?
Sanjiva: Headers attribute inadequate to document some attempted protocol
implementations. So drop them.
Glen: The body is a big bag that bindings pull parts from. Big bag
encourages bad non-modular design. So headers attributes and
f&p support good modular design
JeffM: In practice headers glommed on incrementally and ad hoc
jacek: +1 Glen
tom: Wakes up. Supports Sanjiva.
Straw poll: Remove headers attribute from interface and headers property
from the model
13 for 1 opposed, none lying down in road
RESOLVED: Remove @headers.
ISSUE: Should the body attribute be renamed since the contrast with
headers is gone?
[renaming fracas resumes]
Poll on which names are acceptable:
15 ok with message
15 ok with element
5 ok with body
14 for data
many mj
11 content
Preference poll on winners:
8 favorite for message
8 favorite for element
1 favorite for data
Runoff poll on winners:
10 for message
8 for element
RESOLVED: rename @body to @message.
[Issue can be reopened if name seems confusing.]
ISSUE: Considering the details attribute in infault
poll called for whether to rename details att. message
3 for details
10 for message
RESOLVED: Rename @detail to @message
ISSUE: is there a proposal for removing headers from the binding
JeffSch: Wants to have binding headers declarable as the bare fallback
support in wsdl 2.0
Glen: Insists that this approach is either useless (except for cookie
case) or promotes bad design or both
TomJ: Supports having binding header descriptions.
[general remarks about how much, and in what detail, and by what means to declare in wsdl:definitions]
poll to determine whether removing soap headers from binding
many opposed
2 favor
ACTION: Glen to write up his proposal and rationale on headers
ISSUE: headerfault
Umit: Sample apps use it in ws-i
-------------------------------------------------------
15:00 Break
15:30 Attributes [26]
[26]
http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/att-0320/GetterSetterStyle.html
ISSUE: Attributes
Umit presentation, uri to come to document
[Umit: the presentation is
http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0038.html]
[JeffSch: http://lists.w3.org/Archives/Public/public-ws-desc-state/2003Oct/0021.html]
Jacekk: Propose to combine get set into one section
TomJ: Driving force for feature has withdrawn request-- so?
Sanjiva: One style uri confusing
JacekK: No, point is one section in document, but one style might be OK too
ACTION: Jacekk to make proposal on combining the get/set styles into one
[Discussion took up the subject of Sanjiva's and Steve Grahams posts. ggf
wanted first class treatment to meet objections against creating extensions
to wsdl. Result, however, might not be adequate for their needs "obfuscated".]
Sanjiva: Resource attributes don't have to be captured in WSDL for resource
management goals.
[However, this is not necessarily a consensus view in the GGF]
Roberto: Service itself could have properties needing management.
JeffM,Sanjiva: on stateless, stateful, resource behind service, also stevet.
Marsh: Invite people to review and comment during last call on attribute
support adequacy for grid.
Sanjiva: Predicts IBM will not urge wsdl attributes as way to offer needed
extensions for grid.
Marsh: Removal of style and sections on attribute not motivated at this
time.
TomJ: Says that the effort has been undermined by withdrawal of key
advocates.
JeffM: ggf wish for us to provide this is critical factor on pulling
section.
[discussion of schedules, timelines impacting proposal to remove attribute style.]
straw poll (informative only - no action planned): favor dropping
13 favor dropping and 5 against]
[People who had supported effort summarize their rationales for changing
their view.]
Issue: Make @style a list of URIs?
Marsh: Anyone volunteer to say how styles can be composed?
[no one steps up.]
[DBooth: To be clear, a nice thing about a style attribute is that it places
no burden on implementors that don't care about it. A WSDL generate
the doesn't care about it doesn't have to use that style, and a WSDL
processor that doesn't care about it can alway safely ignore it.
For this reason, the cost of adding a style attribute to our spec is
minimal: only the spec-ese that is required to describe it.
(And Sanjiva adds: Plus the additional burden placed on other sp]
-------------------------------------------------------
16:00 Updated definition of equivalence (Sanjiva)
[remaining for today, http binding and updates on equivalence]
Sanjiva: Substitute interface compatibility for equivalence of service.
details to come.
Glen: Does not think this should be undertaken by wg, could be cool
on a wiki blog.
[Some support for what Sanjiva wants is already in the spec. No further action
anticipated.]
-------------------------------------------------------
15:20 http binding [27]
[27] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0230.html
[Some brainstorming about how to update the HTTP binding. Discussion will
inform Philippe who already has an action to propose an update.]
-------------------------------------------------------
17:00 Multiple inline schemas [20]
[20] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0074.html
ISSUE: treatment of multiple inline schemas
[pauld: Norm Walsh's blog on schemaLocation:
http://norman.walsh.name/2003/11/03/locrules]
[scribe lost connection, hope this stuff gets logged somewhere]
[Chair recreates:
WS-I is revisiting issue of inlined schemas importing each other.
Current recollection is that it was to ban schema import pointing
to a WSDL to mean importing any inlined schemas in that WSDL.
Umit wants inlined schemas and imported schemas to behave the same way,
e.g. schemaLocation is allowed and means the same thing in both cases.
After some discussion, we decided not to restrict xs:import and xs:schema
appearing in wsdl:types. We will not constrain the strategies specific
implementations have for locating schemas (even embedded siblings.)
The question of whether wsdl:import also pulls in schema components from
wsdl:definitions/wsdl:types. Some members expected it should - we need
to check this out more thoroughly.]
17:30 Adjourn
Received on Friday, 7 November 2003 18:17:56 UTC