See also: IRC log
<scribe> Scribe: uyalcina
http://www.w3.org/2002/ws/desc/5/lc-issues/#LC333
<hugo-chair> Proposal from Roberto: http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0051.html
Roberto talks about his proposal. There are four default attributes.
Roberto: This is broken many
ways. Interfaceless bindings do not take these defaults into
account.
... They are ignored for bindings that bind a subset of the
operations.
... Proposal is to introduce a new component model
property.
... In this manner, the default values can be applied to
operations even if there is no corresponding binding operation
component.
Hugo: What is the purpose of the interfaceless binding?
Glen: To write binding rules
across many interfaces.
... Endpoint links them together
Arthur: Is this an extension for SOAP?
Roberto: We are introducing new properties to binding component and
Hugo: Are there any objections?
None noted.
RESOLUTION: Accept Roberto's proposal for LC333
<jjm> And this resolution applies to not just the SOAP mep property, but also to the equivalent HTTP properties, as indicated in Roberto's message.
http://www.w3.org/2002/ws/desc/5/lc-issues/#LC335
Hugo: This is a comment about our
component designators to be very complex.
... We looked at this and decided that the simplification
proposal only targeted a very small subset and decided to
retain our design
The objection is from DC and he is not happy with our resolution. However, there is incompatibility between RDF syntax and XPointer, it is not really our problem.
Arthur: The proposal conflicts
with the definition of barename pointer.
... We are defining a new scheme specific to WSDL. We should
not override an existing scheme.
<dorchard> For the record, I would like to close this issue with no change.
+1 To Arthur!
Umit: I suggest we use Arthur's argument when this issue is brought up to the director.
Arthur: It is not clear how
extensive his proposal is and how it is supposed to apply
... They probably want to apply to an arbitrary WSDL
document.
... Jacek's suggestion may not work because you need to define
how id resolution will work if there is an existing component
with the id.
<JacekK> JacekK: we may imply the ID semantics on the names that are actually unique, the application (wsdl) may define what is an ID
Hugo: It appears the wg does not want to change its position
JacekK: It would have been nice if we could address this problem, but if we can not I can live with this.
Arthur: What is the legality of overriding an existing scheme? We seem to be overriding an existing scheme for bare names.
<dorchard> Jack, one of the earlier possibilites we talked about was making the name have ID type, but that was rejected
<dorchard> The problem is that it doesn't enforce uniqueness within a symbol space across linked documents.
Group starts looking at xptr section 4.2.2 bare names.
Arthur: What is the media type here, isn't it XML for XPointer?
<JacekK> see http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ sec 3.2
<dorchard> A conflict between barenames pointing to IDs and barenames pointing to names will only occur if they differ. An XML processor might get the wrong result with a barename and there's no id in the wsdl element, but it will get the right result if it is a WSDL processor.
JacekK: The 4th definition seems to apply to us.
Discussion about David Orchard's points.
JacekK: I can write a document illustrating the issues here if this needs to be discussed with the director.
Hugo: We may take up on your offer if needed.
DaveO: Lets close the issue. The problems are out of the scope for WSDL.
Hugo: Who would oppose to keeping it closed?
No objections.
RSOL
RESOLUTION: LC335 close with no action
<JacekK> Glen's email: http://lists.w3.org/Archives/Public/www-ws-desc/2005Nov/0021
<hugo-chair> http://lists.w3.org/Archives/Public/www-ws-desc/2005Nov/0021.html
Glen: Not spec ready, but gives
the idea
... Presents the idea
Umit: Isn't this formulation of the obvious?
Glen: yes
Roberto: How does this work with extension? Is it any extension, mandatory extension?
Glen: Even if it is not mandatory, the client may engage the extension anyway and this will change the behaviour.
JJM: Do we need the sentence wrt extensions?
Glen: It is just useful to have the sentence for clarity
DaveO: I like it, it is a good thing. I am surprised why destination properties are not mentioned here.
Glen: It will be good to do that.
Yuenn: We need to address SOAP response MEP as well.
Glen: I can address the destination with the response MEP as well.
DaveO: What about failures?
Glen: I am not clear whether we need to do that. We can still leave it up to the user.
Hugo: What do people think?
... We will wait until Glen finishes addressing the comments
from DaveO and Youenn
... Do we want to do this for SOAP 1.1? It is very
handwavy.
Umit: You can not do this for SOAP 1.1, there is no property, etc.
Hugo: We will concentrate on SOAP
1.2.
... Lets break for 1/2 hour
<charlton> restart at 10.35 JST, 17.35 PST, 01.35 GMT, 02.35 CET
Hugo: We are trying to figure out
how we use the HTTP location to correctly construct the URI for
SOAP response MEP
... Lets talk about CR plans.
... Once we close the WSDL Message to SOAP Message mapping, we
can talk about going to CR.
... We need to decide about the features at risk, the exit
criteria, etc.
... In order to approve the drafts, there are pending editorial
changes. By next Thursday, we can tentatively plan to vote to
go to CR.
Anish: What do we need to do
about the requirements that we submitted to XMLP? How about the
one-way binding? There is already discussion in XMLP.
... Are we going to wait or stick a note into the cr? How is
the scheduling going to work process wise? Are we going to use
the result of their work?
Hugo: We have a note in the
status section already. It is a fairly small change in the spec
if we were to use their result. We can do this after we go to
CR.
... We can make the decision when the time comes.
... Lets have the drafts on Wednesday and plan to go to CR on
the next call
... We will talk about the second proposal from Glen.
http://lists.w3.org/Archives/Public/www-ws-desc/2005Nov/0022.html
Hugo: The first change is to accomodate the SOAP response MEP
Glen: The sentence regarding the extension should also be added from the first proposal. It was omitted by mistake.
Proposal: Proposal 2 + Sentence regarding extensions from Proposal 1
Hugo: Do we accept this proposal?
No objections noted.
RESOLUTION: Proposal accepted for the Issue.
<scribe> ACTION: Jonathan to record the issue formally to the issues list with the resolution recorded [recorded in http://www.w3.org/2005/11/11-ws-desc-minutes.html#action01]
Hugo: All issues are closed!
Hugo: We need to show that our
spec is implementable in an interoperable way
... We need to have current and planned implementations.
Anish: We need to identify the features.
Paul: Our "features" are very fine grained. We need a better grouping mechanism instead of individual assertions.
Hugo: Lets go over all the things
we need to do first.
... We need to come up with exit criteria and test suite
... We need to identify the features at risk. We have couple of
them. We need to identify the period.
Anish: What was the criteria for identifying sth is at risk?
Hugo: We have couple of MEPs. We decided to keep those MEPs to find out whether we will have implementations for.
Anish: This applies to other things in the WSDL document as well. The CR period is for identifying these things.
Hugo: URIPath is also an
example.
... We are doing this in order not to go back to last call,
since some features are already known at risk.
Umit: This criteria applies to the HTTP binding as well.
Anish: If we do not mark HTTP binding at risk, then we have to go to LC.
Umit: However, HTTP binding is in the charter.
Hugo: Shows the URIPath and why this should be at risk.
Paul: It is an important phase
for the spec to identify certain things are not implementable
or there is no interest in them.
... Removing stuff is good to get the spec to be
implemented.
<Arthur> "Perfection in design is achieved not when there is nothing more to add, but when there is nothing more to remove." - Antoine St. Exupery
Paul: what is the purpose of standardizing sth if there is no interest in it.
Youenn: Process q. If we remove the HTTP binding, do we need to recharter?
Hugo: We need to go to the
director and then probably make an announcement to the AC that
we are changing the charter. For example, there is
SPARQL.
... Making such a change to the charter is not good.
Youenn: SOAP binding is using HTTP binding. So, some part of it is required to be implemented to be anyway. Will this be sufficient to save the HTTP binding?
Hugo: Probably not. If you just implement the facets, it is not enough.
<Arthur> "If in doubt, throw it out." - Michael Marks
Hugo: I need to investigate
it.
... It is a very big change to our charter.
Umit: This is a problem. What I think we should do is to recharter now since we need to do it anyway by marking HTTP binding at risk. In this way, we do not have to go back to LC if HTTP binding is not implemented.
Anish: We decided not to split
the document because the changes that are made to the binding
were not large enough to force us to go to LC.
... We discussed this yesterday.
... If we think that the implementations for this binding is
not going to happen, splitting the documents seem to be a very
good solution.
Youenn: If we do this, there is a normative dependency between the SOAP binding and HTTP binding. We will have a problem.
Anish: Wouldn't these changes be structural rather than substentive? Can't we solve this by cut and paste?
Hugo: I need a couple of days to think about this.
Arhur: We have people who want to use it externally. SPARQL points to the binding.
Umit: I am really concerned that going back to LC will kill WSDL 2.0 for good after 4 years. Lets work not to go to LC.
Hugo: Who has WSDL 2.0 implementations?
Arhur: There is work in progress, Apache.
Hugo: Who will participate in the testing?
Arthur: Emerging tech group in
IBM will probably have an implementation
... Eclipse will integrate Apache's implementation.
<alewis> who's the woden project associated with?
Roberto: Going to CR may help the companies to commit to the development of resources.
Woden is the apache project.
Arthur: It is in incubator status.
Glen: Axis 2 may do the HTTP binding. We will plan to switch to Woden at some point. We also have an HTTP mode.
Hugo: From the process
perspective, we need 2 implementations.
... One option is to demonstrate implementation of each future
and report.
Arthur: I wrote a document a
while ago. We should test three different things.
... We need good and bad documents. We need at least one test
case for each optional feature.
... We have about 53 test cases currently in the test
suite.
Paul: We need high level groups.
Those should be buckets for assertions.
... We can use high level sections of Part1 and Part2. We could
alternatively use the Primer contents.
... such as component model, interface inheritence, etc.
Umit: What about the items that are subject to minority opinions?
Arhur: There is interest in REST style WS.
Roberto: Wg members should be able to bring up the list of features that they consider to be at risk,
Hugo: Exit criteria must have two interoperable impl of each feature. We produce a test suite with an impl report.
No objections to this exit criteria by the wg.
Hugo: Our charter also covers SOAP 1.1 binding so our test suite should also cover that.
Lets discuss what may be at risk. At lunch time think about those features that may be marked as risk
<alewis> something-twenty-five, then?
<hugo-chair> Scribe: TonyR
Hugo: speaking as team contact: publishing spec with lots of items "at risk" does not show much confidence
<scribe> Chair: how I'd like to do this - run through Paul's list of features, ask which ones people wanted marked "at risk"
Paul has sent the list to the mailing list, but waiting for it to percolate through
<scribe> Chair: things raised as "at risk" so far:
UNKNOWN_SPEAKER: URIPath - the
"curly brackets" notation
... MEPs - specifically: some of the MEPs are at risk
AmyL: what are the criteria to
keep MEPs in the spec? How do we count the
implementations?
... Can we count the ones that are currently in use as not
being at risk?
<scribe> Chair: so far we have in-out and in-only, and we were not intending to mark them as at-risk
AmyL: that was what I was thinking
Anish: does it have to be an implementation? is a spec sufficient?
<alewis> i think that having an external *dependency*, rather than suggesting "interoperability" ought to be the criterion here.
Anish: no, what I meant was, do we need a spec? Or would a well-known implementation suffice?
<alewis> +1 to hugo's formulation
<scribe> Chair: we will keep MEPs for which we have evidence of use.
UNKNOWN_SPEAKER: we'll decide on
a case-by-case basis
... that may be inclusion in a spec, well-known
implementations, etc
Anish: what about out-only?
Glen: that's functionally in-out - there is an in message bound to the URI that solicits the response
<pauld> list of WSDL 2.0 'features': http://lists.w3.org/Archives/Public/www-ws-desc/2005Nov/0023.html
Discussion of out-only ends with Anish conceding the point
The status of these two features as being at-risk is agreed
Now moving to Paul's list of features
<scribe> Chair: which features should be marked at risk?
Umit: HTTP binding?
<scribe> Chair: Features and Properties?
Roberto: IRI style
... Multi-part style
<Arthur> I've got them on my list. Oh I've got them on my list. And they none of them'd be missed. They none of them'd be missed.
Umit: the HTTP binding should be marked at risk because we have no evidence that we will see two interoperable implementations
Glen: can we remove the HTTP Binding without forcing the spec back to LC?
Umit: yes - not a big
operation
... we cannot afford to return to LC - we will lose all
momentum
Arthur: object to pulling this
binding at this late date
... Apache/Woden will implement the complete spec, including
HTTP binding
... IBM are proponents of light-weight interfaces, including
REST - no formal declaration of implementation
<pauld> +1 to Arthur
Anish: don't believe it should be marked at risk, but would like to see it split into a separate document. Oracle is likely to implement the HTTP binding, albeit perhaps not during the CR period
<uyalcina> The position that I am advocating is not that HTTP binding is unimportant or should not be targeted. I am making the practical observation that we will not have interoperable implementations during the CR period. I do not want to go back to the LC period again.
<uyalcina> I would prefer a practical solution either marking at risk or divide the spec.
Jean-Jacques: just checked the spec - it appears feasible to split it in two, with a bit of copying
<uyalcina> I do not care which way we proceed, but this specification needs to go to CR.
<uyalcina> and get out of CR.
Hugo: For W3C: as team contact,
point out that this is a team deliverable.
... we have evidence that people want to use the HTTP binding -
the DAWG used the HTTP binding
... if we can split the spec in two now, then we could equally
well do it during CR
Anish: aren't there different criteria during CR?
Hugo: implementation experience
will be the same with or without
... do not want to mark it at risk
Umit: are you opposed to splitting the document?
Hugo: doubt that it will
help
... the problem is not how it is organised, but the
content.
... (as chair) giving people a chance to make formal statement
- closing queue soon
Roberto: do not want to return to
LC again. Support splitting the document, but do not support
marking it at risk because it discourages involvement
... problem with the HTTP binding is already a lack of
involvement - it's somewhat experimental
... question of whether it captures what designing REST
services is about.
Jean-Jacques: if we split the bindings into separate documents, can we run the two bindings on separate tracks?
Anish: we could reverse dependency around, so the HTTP document depends on the SOAP one
Jean-Jacques: question of timing: how long will we have for CR?
Hugo: could be 2 weeks to 6 months - prefer about 3 to 4 months
<scribe> Chair: it's inappropriate to call the question of splitting the document today, given that we discussed it yesterday
DECISION: HTTP Binding not marked
at risk
... IRI Style / Multipart Style not marked at risk
Next item for consideration: Features and Properties
Umit: should be marked at risk because there are two formal objections against this
Hugo: formal objections do not
affect our ability to implement
... so it's inappropriate to mark at-risk
Roberto: there's division in the industry on how we should implement these
Anish: just because there are formal objections is no reason to mark at-risk - would object to marking this at-risk
<GlenD> Roberto, there's already a clear marker that there are formal objections about this. I think that serves the same purpose you were trying to get across (warning people it's contentious).
Anish: have been waiting a long time for response - marking it at-risk sends the wrong message
<Roberto> I think that potential adopters of WSDL should find out about areas which are this unsettled from the specification itself, not from some WG/process-related page
<uyalcina> +1 to Roberto
Paul: as a customer, hate duplication of ways to achieve things - have been waiting for another way to achieve this, but it has not appeared.
<GlenD> Roberto - it is in the spec itself.
Paul: There are other specs which will be using F'n'P, removing them at this late stage would damage other specs
<Roberto> Glen, even if all the objections were withdrawn, the risk factors would remain
Youenn: agree with Paul:
WS-Addressing, WS-I18N will be using Features and
Properties
... as enabling MTOM usage. Should not be marked at risk
Jean-Jacques: any other users?
<uyalcina> The Features and Properties used are not F&P at the abstract level but at the SOAP level.
<uyalcina> Therefore it is not a fair comparison.
Hugo: "Handling Privacy in WSDL 2.0" paper describes another use
<pauld> http://www.w3.org/TeamSubmission/p3p-wsdl/
Hugo: goal of the note was about making privacy statements about Web services, their operations, the information carried by their messages, etc.
<uyalcina> Describing a SOAP feature or SOAP property does not get to the abstract layer of WSDL.
Hugo correctiing scribing:
<GlenD> To add to Umit's comment - it's possible to write a SOAP feature whose markup in WSDL is not written in terms of the <feature>/<property> elements
Jean-Jacques: has the membership making the objections changed?
<Zakim> GlenD, you wanted to call the question
<pauld> ack ack ack ack
Glen: wants to call the question
<GlenD> or "queue queue queue queue"
<GlenD> woops
<GlenD> don't minute that
<GlenD> Whoa! OR that!
Formal vote on marking this at risk
Formal vote question: Should we mark Features and Properties at risk?
CA: no
Oracle: no
Sonic: no
SAP: yes
Canon: no
Sun: abstain
BT: abstain
IBM: yes
W3C: abstain
Total: 2 yes, 4 no, 3 abstain
Summary: only features marked at risk are URIPath and the unused MEPs
<scribe> Chair: we could publish CR version at the beginning of December
Arthur: need 3 months to implement (Woden)
Glen: 3 months sounds reasonable for Axis 2
<scribe> Chair: we can adjust the period at the time of voting on CR (next Thursday)
Glen: suggest we divide the spec equally among the member of the WG, and have everyone do the work - would help to have everyone re-read the spec
Umit: volunteers to take the RPC and Service References section/s
<scribe> ACTION: Arthur to construct instructions sheet, and assign sections for each member of the group to insert assertion markup [recorded in http://www.w3.org/2005/11/11-ws-desc-minutes.html#action02]
Arthur: post-assertion markup, we
need documents for testing - good documents and bad ones, where
the bad ones violate exactly ONE assertion
... tools to do the checking will use these test
documents
... just checked in a test suite coverage summary
<GlenD> (Arthur describes the test case coverage report)
Arthur: note that all test
documents are schema-valid - we do not intend to test
schema-invalid documents
... so think as you mark-up assertions, think of a test case
that violates that assertion
<scribe> Chair: moves a vote of thanks to our host, Hitachi
ADJOURNED