See also: IRC log
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Tom Jordahl Macromedia
Jacek Kopecky Systinet
Sandeep Kumar Cisco Systems
Philippe Le Hgaret W3C
Amelia Lewis TIBCO
Jonathan Marsh Chair (Microsoft)
Ingo Melzer DaimlerChrysler
Dale Moberg Cyclone Commerce
Jean-Jacques Moreau Canon
David Orchard BEA Systems
Bijan Parsia University of Maryland MIND Lab
Arthur Ryman IBM
Jeffrey Schlimmer Microsoft
Jerry Thrasher Lexmark
William Vambenepe Hewlett-Packard
Kevin Canyang Liu SAP
Lily Liu webMethods
Jeff Mischkinsky Oracle
Adi Sakala IONA Technologies
Igor Sedukhin Computer Associates
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
Prasad Yendluri webMethods, Inc.
Scribe: GlenD & DBooth
Scribe: MINUTES APPROVED: http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0043.html
Scribe: ACTION: 2003-09-18: Marsh to review the QA operational guidelines. [PENDING]
<Scribe> ACTION: 2003-10-09: Bijan to
look into message extensibility Issues (Appendix E, Jacek's review) wrt
RDF data, and discuss with Jacek.
<Scribe> ACTION: 2003-11-03: PaulD to work out proposal for a top-level fault in more detail. [DONE]
<Scribe> ACTION: 2003-11-03: Umit (with help of Glen) will write up a proposal for normative dispatching feature. [PENDING]
<Scribe> ACTION: 2003-11-04: Glen to write up rationale for removing headers (and?) proposal for a generic header-adding property/feature. [PENDING]
<Scribe> ACTION: 2003-11-20: GlenD to write up Schemas in imported WSDL stuff in specese. [PENDING]
<Scribe> ACTION: 2003-12-11: Philippe: write/update proposal for HTTP binding and post to the list that "reflects" the "consensus" of the group. [DONE]
<pauld> Cannes: http://www.w3.org/2003/08/allgroupoverview.html
... Registration: http://www.w3.org/2002/09/wbs/35125/tp2004/
Jonathan: discussed mailing list for media-type description... wha happen?
DBooth: no action item yet, so no action yet
Jonathan: There's a mail from Anish, so this should move forward
DBooth: I'll request one today.
Scribe: Assign issue numbers
... * Schemas in imported WSDL [.2]
... * Proposal for combining the two attribute operation styles [.3]
... * Appendix E cleanup [.4]
JJM: OK, will assign numbers to these
Scribe: Clarify element + type - http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0109.html
... oops wrong URL
... RESOLVED: ISSUE clarify-element-and-type CLOSED
... - Issue #15 [.5]: Missing <document> tag for operation arguments
... RESOLVED: ISSUE #15 CLOSED
... - Issue #8 [.6]: Inconsistency in definition of attribute extensibility
... RESOLVED: ISSUE #8 CLOSED
... - Issue #92 [.7]: Include cycles: completed with last week's action?
... RESOLVED: ISSUE #92 CLOSED
... At this point in the telcon, the road diverges in a number of fascinating directions
... HTTP binding, various older issues, etc...
... Issue #24 is the road we choose
... literal vs. encoded - do we really adequately deal with this?
Tom: this arose from soapbuilders conversation - we seem to have
actually flushed SOAP encoding in WSDL unless we define an actual SOAP
encoding schema language
... WS-I killed SOAPENC, so maybe it doesn't matter
Scribe: Glen + Paul: our customers still use encoding
Tom: We can do RPC in WSDL 2.0, but not encoding - should we deal with that?
Jacek: I am still planning to provide SOAP data model schema language
Amy: by providing support for multiple schema languages, it's
covered by WSDL 2.0
... out of scope to do SOAPENC
Jacek: it's in our requirements to do so
Amy: the WG shouldn't actually do this work, though we might look at a version
Jacek: This could be an appendix or a note, or a spec on
... would prefer a W3C note or something like that
Jonathan: is this for legacy customers, or for people building new stuff?
Jacek: the latter.
... but we wouldn't need this if we just restrict to the XML data model, and not the SOAP 1.2 data model
Jonathan: close this issue, but open new one on whether we should provide schema language for SOAP data model?
Arthur: there's been lots of WS-I feedback, which has said "kill
... encoding doesn't work when it gets complex
Tom: there's a ton of interop with RPC/enc services now
Paul: agreed, literal interop is much worse right now
Philippe: maybe we should talk to BP group about this topic?
Amy: if we make sure our spec supports additional schema languages, we're OK
Tom: if we don't standardize this, who puts it in the tools?
Jonathan: this could be "standard" even if it's not done here
Scribe: Jonathan doesn't want this to impact our timeline...
Arthur: most legacy systems aren't designed with good SOA, so
even if you build interfaces from existing code, you still often need
to clean things up
... encoding was useful, but these days people start from XML interfaces...
<pauld> +1 to Arthur, but I'm worried if WSDL 2.0 can't easily express section 5 encoding, then it's not very future proof.
DaveO: we're not big fans of encoding
... Do we have a problem with not being able to describe all of SOAP 1.2?
<Arthur> in practice, legacy data structures are simple records, not graphs
Jonathan: please ask your customers / people in your organizations if this is important
<Arthur> a "tame" subset of SOAP encoding can be described by XSD
Scribe: RESOLVED: CLOSE ISSUE 24, OPEN NEW ISSUE RE: ENCODING
... Issue fault-name-uniqueness [.1]: Should faults be named with QNames?
Glen: Paul's proposal affects this
Paul: if we hoist, they get QNames
Scribe: RESOLVED: PROPOSALS AS WELL AS "BUG" TYPE ISSUES WILL GET NUMBERS AS WELL
PLH: May want to mark the style, but not required.
... For each element, it must be a simple type, with the exception of binary content.
... E.g., want to do GET or POST on a car. If you append the license plate #, you identify the car. If you also append a property, you get that property.
... You can put some part of the message both in the message and in the query parameters, as discussed last week.
... The diff between GET and POST is that with POST there will be duplication in the URL and the content of the body.
... But with GET there is no body.
... I added one restriction on top of RPC style rule: You cannot have more than one element with the same local name in the sequence, because I'm not using any kind of prefix -- only local names.
... If you look at the example, I bind into the query parameter.
... There's a special case when you're mapping a list of simple types. The element is repeated in the query parameters.
... The xml encoding mechanism involves just putting whatever you have in the body.
... We thought it would be useful to accommodate existing practice in WSDL.
... For multipart encoding, you map each element into the body.
JMarsh: This is intended to update Philippe's last proposal.
... Which parts are controversial or not?
DaveO: I plan to review it, but haven't yet.
GlenD: I plan to comment by email. We're describing some
interaction from one node to another.
... One property is the location of where to send the message, another is what content. This proposal makes the line between those fuzzy.
... Maybe other mechanisms could better make that distinction.
... Need to manipulate the URI, but mixing it in may be confusing.
Scribe: Just another quick commment - I think of this as perhaps
the same kind of thing as headers/body
... (silence from others)
JMarsh: We'll take it to email.
Scribe: [GlenD departs. DBooth takes over as scribe.]
PLH: In the RPC rules, there's no mention of what happens with attributes.
Tom: Not allowed to have attributes.
Jacek: You never end up with a schema with attributes, because it tells how to make the schema and doesn't make them.
Tom: Probably should say no attributes allowed.
Tom: Need to clarify that the children cannot have attributes.
Jacek: Why not? Why shouldn't the value be structured to fit
... We presume the type of parameters is XML Schema type. Why constrain it? As signature, it could be a struct with some fields.
... Do we allow attributes? We can't disallow them. Attributes are a part of the parameter types.
<plh-lap> I corrected my previous statement. the spec says: " The complex type that defines the body of an input or an output element MUST NOT contain any attributes."
Tom: Rules are there to protect them. What if I have a structure of type string with attributes?
Scribe: (More discussion)
... (Tom and PLH now agree with Jacek)
Jacek: The binding may constrain the types. The HTTP binding proposal is already constrained to simple types, which cannot have attributes.
JMarsh: SHould we also give this style a URI, and put it in the style section?
Jacek: If we flag operations with that interface, then we know they can be bound to HTTP.
Tom: Should use only a single RPC style, not two.
JMarsh: So restrict RPC to simple types?
Tom: No. Just don't name the other style. :)
Jacek: There are reasons for marking them for RPC style for stub gen, and HTTP style for reuse.
Tom: Seems like too many options.
Jacek: Maybe flagging an operation as conforming to a style should not be one attribute, but by an extension: using an attribute in the namespace for the RPC style.
<jeffsch> sounds good
Jacek: And another attribute from another namespace could mark another style.
JMarsh: Could also have the attribute be a list of URIs instead of a single URI.
Tom: Don't like it on an emotional level.
dbooth: Should we first ask if we want to allow an interface to be simultaneously marked as conforming to multiple styles, and then decide the syntax of how to do it?
PLH: If you don't use a URI replacement, and everything goes into the content, you don't have restrictions.
Jacek: Could still mark it as conforming to HTTP style by default, but i agree it would be awkward.
Roberto: Strange. Style is meant to be use above WSDL.
... In Java, etc. you have conventions for methods, etc. When you generate your schema, you lose that information. Style was intended to recover that information. Here we're talking about using style in a very different way.
Jacek: No. HTTP binding will still impose the restrictions. If I have an interface and want to indicate to users that it can be bound to HTTP, I also might want to do it explicitly.
JMarsh: I view this as additional annotation that wouldn't constrain the HTTP binding.
dbooth: It's really just adding an assertion about the schema.
JMarsh: I think style may be very useful, e.g., vendor-specific stuff. Since it's a hint, the underlying interop should not be affected.
Roberto: But I'm worried about style being another extensibility axis.
Jacek: This case fits that direction. The operation style is another axis of extension. That's why Jeffrey suggested folding it back into the general extensibility mechanism.
JMarsh: Are there questions on what the restrictions are?
... There is an issue against PLH's proposal, which needs to be tracked.
PLH: We should call it "URI style" -- not "HTTP style".
JMarsh: Those same restrictions might be useful in other
... Should record an issue: Is it sufficient to be able to mark an interface with a single style versus multiple styles?
ISSUE: Is it sufficient to be able to mark an interface with a single style versus multiple styles?
JMarsh: And GlenD asked if it's good practice to extract part of your content to parameterize your URI.
PLH: What if you start using fragids? My current proposal: Don't go there.
JMarsh: I'll note that in the thread.