WS Description

10 Feb 2005

See also: IRC log


Rebecca Bergersen, IONA Technologies
Allen Brookes, Rogue Wave Software
Roberto Chinnici, Sun Microsystems
Paul Downey, British Telecommunications
Youenn Fablet, Canon
Hugo Haas, W3C
Anish Karmarkar, Oracle
Amelia Lewis, TIBCO
Kevin Canyang Liu, SAP
Jeff Mischkinsky, Oracle
Dale Moberg, Cyclone Commerce
Jean-Jacques Moreau, Canon
Tony Rogers, Computer Associates
Arthur Ryman, IBM
Adi Sakala, IONA Technologies
Asir Vedamuthu, webMethods
Sanjiva Weerawarana, IBM
Umit Yalcinalp, SAP
Glen Daniels, Sonic Software
Tom Jordahl, Macromedia
Jacek Kopecky, Leopold Franzens Universitat Innsbruck
Bijan Parsia, University of Maryland MIND Lab
Prasad Yendluri, webMethods, Inc.



Approval of Minutes

Last week's minutes approved.

Review of Action Items

(No updates)


(Mention of upcoming Tech Plenary)

Test Suite

JMarsh: We have 8 test cases now. Please contribute!

April F2F

JMarsh: Still seeking a host. GlenD is checking if he can host on West coast. Volunteers to host?
... For June F2F we have an offer for SAP to host in Berlin.

Asir: When do we close the window for Last Call issues?

JMarsh: That's up to us.

<Marsh> ACTION: Marsh to consider a cutoff for LC issues.

Asir: Can we publish new spec snapshot before Tech Plenary?

JMarsh: We could, but not sure we can get the editorial work done in time. Editors drafts may be sufficient.


JMarsh: Need to confirm what people signed up to do:


+ Section 7.5 Versioning and Service Equivalency (Paul)

+ Section 7.6 MTOM Support (Marsh)

+ Section 7.11 Service References (Arthur)

+ Section 7.12 XML Schema Examples (Paul)

+ Section 7.13 Multiple In-Line Schemas (Arthur)

+ Section 7.14 The schemaLocation Attribute (Arthur)


Section 7.15 Mapping to RDF and Semantic Web - Jacek? (JMarsh w check)

Section 7.2 Features and Properties - GlenD?

Section 7.3 Import mechanism and authoring style - Arthur volunteers

<Marsh> ACTION: Marsh to move 106 up on the agenda.

Section 7.8 Operation Style and RPC - Umit volunteers

Section 7.4 Multiple Logical WSDL Documents Describing the Same Service - dbooth volunteers

Section 7.7 Security Considerations - NEEDS VOLUNTEER

Media Type Description issues

Umit: Haven't heard anything from Henry.

JMarsh: Could have a slot at Tech Plenary for Henry to discuss it.

<scribe> ACTION: JMarsh to ask Henry to respond about media type issues with examples

Last Call Issues

Component name consistency: Asir thinks there are non-editorial issues to discuss.

Asir: Need to discuss some of the names.

<scribe> ACTION: Asir to say which component names need discussion

Reference to WS-A from ONM:

JMarsh: WS-Addr draft agreed to make ref to ONM Best practices note in WSDL 2.0 spec.
... Any issue adding a non-normative ref to WS-Addr in our spec?

RESOLUTION: Add non-normative ref to WS-Addr spec

<scribe> ACTION: Arthur to add non-normative ref to WS-Addr spec

Media Type Registration

DBooth: Listed changes.

Arthur: Incorporated them.

DBooth: One more change - minor change to the intro to that section.

... The process involves different steps at different times.

... As part of moving out of LC, the introduction must say "is being submitted"

JMarsh: Think we'll need another LC.

DBooth: OK, then this isn't necessary at this point.

... But there's no harm.

... Don't expect changes in this area, do we?

Arthur: Perhaps some tweaks in the frag id.

DBooth: Don't think that changes the reg.

... If it's OK, I'll get that added.

ACTION: DBooth to mail Arthur change to wording on media type registration, Arthur to incorporate.

Issue LC5f: QA Review on WSDL 2.0 Part 1, intro and conformance issues

DBooth: We tried to outline what needed to be change in order to effect the shift from "processor conformance' to "document conformance."

... We identified places in the spec that referenced "WSDL processor" and proposed changes.

... One part had a significant question:


... We outlined three options on how to mandate XML Schema.

... Without a "processor" we can't mandate XML Schema.

DBooth: Option A: treat xs:schema and xs:import as pure extensions. Need wsdl:required="true". Means that we can't force a processor to support XML Schema.

... Option B: Treat xs:schema and xs:import specially in WSDL 2.0, and say

that there is an implicit wsdl:required='true' on each of them.

... Option C: Define new WSDL elements for schema and import.

... Wanted to see what people thought about the proposal, and those options.

... Do people generally like this?

JMarsh: Feedback?

<Marsh> JeffM: What if I don't use portTypes, does my processor need to support them?

JeffM: If you want interop, you need a set of common features to be supported.

Arthur: You can say that XML Schema is part of the WSDL 2.0 language and make schemas be a part of the test suite.
... We could explicitly include them in our schema (rather than as * extensions)

<pauld> at this point prefers B, fwiw

Asir: I prefer options A or B. This also raises the issue of permitting other schema languages.

<asir> webMethods issue on 'Pluggabiliity of Schema Languages" is http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC70

Sanjiva: Do xs:schema and xs:import allow the wsdl:required attribute?

dbooth: good question

<Arthur> the current definition of <ws:types> is <xs:sequence>

<Arthur> <xs:any namespace='##other' minOccurs='0' maxOccurs='unbounded' />

<Arthur> </xs:sequence>

Sanjiva: Seems like option B is best.

<umit> B is the best solution

<Marsh> ACTION: Marsh to schedule discussion of LC70 along with LC5f.

<Arthur> wsdl20.xsd does not explicitly refer to <xs:import> or <xs:schema>

(No decision yet; waiting to see if DaveO will do a counter-proposal)

<scribe> Topic: Component model changes

JMarsh: Issue is about distinguishing features that were specified on a component versus being inherited.

Arthur: Inconsistency. Also rules for what features are in effect is an important part of the component model. Came up with rules at Melbourne meeting. Would be better to use different names for features defined directly versus those inherited. E.g. "in-scope" features.

scribe: and "all-" to indicate all of them.
... For an operation you'd have "in-scope" properties.
... For every component, we should distinguish between those that are defined on the element and those that are obtained from the parent.

Arthur: Text says how to compose F&P, but not explicitly in component model.
... In the case of interface, its like a derived property, whereas on others it is direct. WE should be consistent about naming these properties.
... Let's put the Melbourne rule in the component model.
... E.g. look at BindingFault.
... We have a paragraph to say what is the full set of properties. Let's instead of an "in-scope" property with them all.

Sanjiva: So property composition section could then be removed?

Arthur: For each component there should be the rule for computing in-scope properties.
... There are some tweaks for individual components, though usually they just come from the parent.

<Roberto> in which section of the spec is the special rule for interfaces?


<sanjiva> for properties

Asir: Property composition section and Feature composition section would disappear and mapping for them would appear in different component. Want to see the full proposal for this.

<Roberto> but doesn't talk about inheritance

Umit: Why bother to put all this in the component model? If you fix the anomoly with inheritance, then this problem goes away. I don't want to distribute the rules.

Arthur: You're proposal for changing the definition of interface is fine.

<sanjiva> Roberto: see table 2-2 in section 2.2.3; sorry

Umit: Interface should not include inherited properties, but instead should go into the composition model for properties.

Arthur: Then we'd also have to treat operations and faults that way.
... But I think it's simpler to split these into direct versus in-scope.

JMarsh: Putting more into the component model permits formal specification by z notation. What's the downside?

<Roberto> I see. I guess we wanted to mimic what we do for operations and faults.

Asir: Positive side effect: It improves round-tripping WSDL documents.

Arthur: I'm not going to do another proposal, because I'm not proposing anything new. I'm only proposing splitting apart things that are not bundled together. We should decide and move on.

Umit: The way you look at prop values that are defined at multiple levels and the closest one wins, so that would have to be rolled in, right?

Arthur: Yes. GlenD agreed to this in Melbourne. For Features, True trumps. For Properties, you get all the constraints, i.e. the intersection of the value spaces.

Option 1: Arthur's proposal

Option 2: Umit's proposal to fix interface

Option 3: Status quo

Arthur: My preference is to combine options 1 and 2 to have all of this discussed in one section.

Asir: This is really about stylistic inconsistency.

(Option 2 would not involve an "in-scope" properties, though both options would involve fixing interface.)

<Arthur> Option 1 introduces {in-scope properties} and {in-scope features} to CM

<Arthur> Option 1 doesn't

<Arthur> Both Option 1 and 2 change def of Interface

JMarsh: So the distinction between these options is whether we use an in-scope property versus rules for walking the tree.

<Arthur> Option 2 doesn't

Straw poll: Option 1: 5 option 2: 2 Option 3: 3

Run-off between options 1 and 3: Option 1: 6, Option 3: 7

JMarsh: Close enough to merit further discussion on list, and decide next week.

LC105: Proposal for Simplifications to the Component Model

Asir: Want full proposal for what info set equivalence means. Arthur says its something we define. Would rely on Post Schema Validation Infoset (PSVI). In some cases it is unworkable, so it depends on whether we can finesse those cases.

JMarsh: In some sense it doesn't really matter how we do it. As long as the algorithm always produces the same result then you can compare.

Arthur: We introduced the notion of equivalence primarily for diamond inheritance. But now we're trying make it more powerful by permitting inconsequential changes to documents to be permitted as still equivalent.

JMarsh: Then this sounds like we just made a mistake originally in using the component model in defining diamond inheritance.

Asir: There's a style property in the operation. It's a straight mapping to the infoset. If it's absent then . . . (missed).

Arthur: But the purpose is to permit people to copy a document elsewhere. Why would there be a difference between the two documents?
... You're saying that you have two different documents,
... with the attribute missing in one of them.

Asir: Yes

Arthur: Do we need to accomodate that level of flexibility, or just duplication that results from copy and paste of documents.

Umit: We have inheritance rules all over. Wouldn't that prevent us from reasoning about the component model?

Arthur: No. Right now I can have two equivalent components with the same name.
... Virtually all Schema processors give an error when there are duplicate definitions of the same element, even if they are the same.

JMarsh: Issue will be moot if we decide we don't want to preclude people from putting property type extensions at the top level that can change the behavior in the document.
... Today different properties can cause two otherwise identical interfaces to differ.

(Topic be continued)


Summary of Action Items

[NEW] ACTION: Arthur to add non-normative ref to WS-Addr spec
[NEW] ACTION: Asir to say which component names need discussion
[NEW] ACTION: DBooth to mail Arthur change to wording on media type registration, Arthur to incorporate.
[NEW] ACTION: JMarsh to ask Henry to respond about media type issues with examples
[NEW] ACTION: Marsh to consider a cutoff for LC issues.
[NEW] ACTION: Marsh to move 106 up on the agenda.
[NEW] ACTION: Marsh to schedule discussion of LC70 along with LC5f.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.110 (CVS log)
$Date: 2005/02/10 17:40:20 $