See also: IRC log
Last week's minutes approved.
(No updates)
(Mention of upcoming Tech Plenary)
JMarsh: We have 8 test cases now. Please contribute!
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
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
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
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.
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:
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0099.html
... 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)
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> 2.8.1.1
<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 2.8.1.1 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.
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)
ADJOURNED