WS Description Teleconference
18 Dec 2003

Agenda

See also: IRC log

Attendees

Contents

• Topics
  1. Approval of minutes
  2. Review of Action items
  3. Administrivia
  4. Task Force Status.
  5. New Issues.
  6. Closing issues
  7. Issue 85: HTTP binding options
• Summary of Action Items

Approval of minutes

Scribe: MINUTES APPROVED: http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0043.html

Review of Action items

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.
... PENDING

<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]

Administrivia

<pauld> Cannes: http://www.w3.org/2003/08/allgroupoverview.html
... Registration: http://www.w3.org/2002/09/wbs/35125/tp2004/

Task Force Status.

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.

New Issues.

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

Closing issues

Scribe: Clarify element + type - http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0109.html
... oops wrong URL
... http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0030.html
... RESOLVED: ISSUE clarify-element-and-type CLOSED
... - Issue #15 [.5]: Missing <document> tag for operation arguments
... http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0031.html
... RESOLVED: ISSUE #15 CLOSED
... - Issue #8 [.6]: Inconsistency in definition of attribute extensibility
... http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0032.html
... RESOLVED: ISSUE #8 CLOSED
... - Issue #92 [.7]: Include cycles: completed with last week's action?
... http://tinyurl.com/ysgl#x92
... 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
... http://tinyurl.com/ysgl#x24
... 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 systinet's server...
... 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"
... 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 DATA LANGUAGE
... Issue fault-name-uniqueness [.1]: Should faults be named with QNames?
... http://tinyurl.com/ysgl#xissue%20fault%20name%20uniqueness

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

Issue 85: HTTP binding options

<plh-lap> http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0051.html

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.

<plh-lap> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html#RPCStyle

Tom: Need to clarify that the children cannot have attributes.

Jacek: Why not? Why shouldn't the value be structured to fit attributes?
... 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?

Scribe: (none)
... 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 contexts.
... 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.

Summary of Action Items