See also: IRC log
<Arthur> scribe: Arthur
<Jonathan_Marsh> scribe list: arthur, charlton, umit, tony
comment 12 of 344. (LC344#12), due 2005-10-06.
<scribe> DONE: LC344#12
<scribe> DONE: No action required.
Date: 2005-11-10
<hugo> ACTION: Hugo to fix language "Binding component assigns quoted string" in SOAP 1.1 binding [recorded in http://www.w3.org/2005/11/10-ws-desc-minutes.html#action01]
<scribe> DONE: This action has been done and is issue LC 361 which will be discussed later.
Assertion markup has been defined.
We need help in marking up the document with assertions. Volunteers? Awkward silence.
<scribe> ACTION: Hugo will start adding assertions to Part 2. [recorded in http://www.w3.org/2005/11/10-ws-desc-minutes.html#action02]
Use numeric range 5000-9999 for Part 2.
Use 0001-4999 for Part 1.
Arthur: I have received interest from a non-W3C member to help with the Test Suite.
Hugo: They can participate as an
invited expert.
... Don't we need to complete the enumeration of the assertions
for CR?
Jonathan: Not necessarily.
Jonathan: Please ask interested parties to review the RDF maaping.
Jonathan: We won't be in REC
status by January. I will ask for a 12 month extension but not
for a patent policy recharter.
... Any change in deliverables will require acceptance of new
patent policy which might inhibit some members to continue. Any
requirements to adopt the new patent policy?
No requirements for the new patent policy were expressed.
see http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC304
Hugo: this issue was raised in the context of describing URIs on the Flickr Web site. I have a proposed solution.
<Jonathan_Marsh> Proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0063.html
Hugo reviews proposal described in http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0063.html
<dorchard> I'm signing off for a few hours.
Much discussion of Hugo's proposal but no concensus.
Jonathan: Who is interested in resolving this?
Paul: We won't pass the "giggle" test if WSDL 2.0 can't describe flickr
Jonathan: FYI, Gil is now an official member of the WG and can voice opinions.
<hugo> Another proposal I made: http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0046.html
<Jonathan_Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0046.html
Break
Resume
Jonathan: We have 3 alternatives to resolve this issue.
1. Hugo's simplified proposal.
2. Hugo's earlier proposal- 2 properties + named serialization + new binary serialization
3. Honouring expected content type in schema as per Note
<Jonathan_Marsh> 0. Do nothing
<pauld> chad, ping
<Jonathan_Marsh> chad, new vote
<chad> new poll
<Jonathan_Marsh> option 0: do nothing
<Jonathan_Marsh> option 1: hugo's simplified proposal
<Jonathan_Marsh> option 2: two properties (hugo's earlier proposal) + binary serialization
<Jonathan_Marsh> option 3: honoring the expected content type from the media type note.
<umit> vote: 3, 2, 0
<Jonathan_Marsh> chad, option 0: do nothing
<Jonathan_Marsh> chad, option 1: hugo's simplified proposal
<Jonathan_Marsh> chad, option 2: two properties (hugo's earlier proposal) + binary serialization
<Jonathan_Marsh> chad, option 3: honoring the expected content type from the media type note.
vote: 1, 0
<TonyR> vote: abstain
<JacekK> vote: abstain
<pauld> vote: 1
<gpilz> vote: abstain
<hugo> vote: 1, 2, 3, 0
<umit> chad: 3, 2, 0
<youenn> vote: 2,1
<jjm> chad: 2, 1
<charlton> vote: 1, 2, 3, 0
<alewis> vote: 1, 2, 0
<Jonathan_Marsh> vote: 1,2
<Jonathan_Marsh> vote: glen: 2, 3, 1, 0
<anish> vote: abstain
<Jonathan_Marsh> chad, count
<chad> Question: unknown
<chad> Option 0: do nothing (0)
<chad> Option 1: hugo's simplified proposal (6)
<chad> Option 2: two properties (hugo's earlier proposal) + binary serialization (3)
<chad> Option 3: honoring the expected content type from the media type note. (1)
<chad> 14 voters: alewis (1, 2, 0) , anish () , Arthur (1, 0) , charlton (1, 2, 3, 0) , glen (2, 3, 1, 0) , gpilz () , hugo (1, 2, 3, 0) , JacekK () , jjm (2, 1) , Jonathan_Marsh (1, 2) , pauld (1) , TonyR () , umit (3, 2, 0) , youenn (2, 1)
<chad> Round 1: Count of first place rankings.
<chad> Candidate 1 is elected.
<chad> Winner is option 1 - hugo's simplified proposal
<anish> chad: details
<anish> chad, details
<umit> I really do not like this solution at all.
<umit> Bad bandaid.
RESOLUTION: LC304 closed with Hugo's simplied proposal
see: http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC345
<hugo> the table I came up with: http://www.w3.org/2002/ws/desc/5/09/wsdl20-adjuncts.html#_http_serialization
<hugo> Proposal is: Hugo's proposal + Charlton's proposal + add disabling attribute for {/} capability
RESOLUTION: Proposal accepted.
Adjourned for lunch.
Back at 1:30PM
<Jonathan_Marsh> Resuming
<charlton> scribe: charlton
Splitting out the HTTP binding
Paul: How much work would it be, and what are the dependencies
Hugo: Editorially it is easy, take the section and put it elsewhere
Marsh: Complicates CR test cases
as well
... Do we believe that we've made changes substantial enough to
invalidate anyone's review (requiring another LC)?
... If splitting out HTTP Binding were trivial, would it be
desirable to split it out and go through another LC?
Hugo: HTTP Binding has been
reviewed by a number of people. If it goes to CR, people will
certainly have a close look at it, and if we rediscover
problems at this stage, then we can split, fix the problems,
and go through another LC
... Speaking against splitting out HTTP Binding
Youenn: We spoke against it this morning. Why do it?
No interest in splitting out HTTP Binding at this point
Marsh: Administrative - checking to ensure we've performed our due diligence
Proposed Text for LC344#5: http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0040.html
Ãœmit: I have a friendly amendment for this: It does not affect the messages on the wire
Arthur: The spec does not speak to programming models at all.
Glen: Does not say how the client interacts with a WSDL, but how it interacts with service
<uyalcina> Proposed sentence: This additional information in no way affects the messages exchanged with the service and ...
Glend: Purely for readability, I'd like a change in the 2nd sentence....
Marsh: That is purely editorial
<GlenD> My friendly amendment is s/by the interface message reference components of the/in/
Glen and Umit's friendly amendements are accepted
<GlenD> ("by" is fine too instead of "in" - either way)
<GlenD> Suggestion - s/by its {style} property./by its {style} property. Note that if any of these specifications are mutually incompatible, the document is invalid./
Arthur: We're trying to get rid of language that states that this is an error. If a document has one or more styles, it must satisfy each style. We can look at messages and determine whether it uses mutually incompatible styles. We can look at a message's use of styles, but not compare two styles.
Glen: Validity is dependent upon whether or not you understand the URI
Arthur: We're looking at a doc
that we've been given, and it is up to the author to determine
whether it is valid. With extensions, there are additional
obligations on the client, but outside of that, the obligation
for validity is the author's
... It is not up to the consumer to validate the document
Umit: We had earlier said that a
publisher of a document is responsible for validity
... Arthur is trying to capture this in this language
... I would not like to see invalid documents indicated by
style
Arthur: This text references URIs - they need to be changed to IRIs
<GlenD> If no Operation component can simultaneously satisfy the set of such styles, the document is invalid.
<TonyR> If no Operation can simultaneously satisfy all of the styles, the document is invalid.
<Arthur> I agree that any subset of styles could be mutually incompatible, not just pairwise.
<TonyR> If no Operation component can simultaneously satisfy all of the styles, the document is invalid.
LC344#5: Agree to the following changes:
<Arthur> 1. umit's suggestion
2. glen's friendly amendment
<Arthur> 2. glen's suggestion
<Arthur> 3. tony's
<Arthur> 4. change URI to IRI
1. umit's friendly amendment
2. glen's friendly amendment
3. tony's friendly amendment
4. update URI to IRI
Umit: Can you write a style that applies only to faults? A fault style?
Arthur: Why can't you do an in
fault in HTTP?
... Does the HTTP Binding only work for certain maps?
Hugo: Yes
Should Operation Styles Apply to Faults?
(follow on to LC344#5)
Marsh: Is this an easy fix? Just add "...or fault..." somewhere?
Umit: I don't think anyone wanted to prevent styles to be applied to faults
Glen: I'd rather that the XML is constrained to something data bindable...
Marsh: We should just be able to add "fault" to this text
Arthur: As written, it seems like a predicate on element reference, but actually is only for message references
Add fault to the text, and have some editorial cleanup of the text
<Arthur> Section 2.4.1.2 needs to be amended to include Faults and to not just be applied to the {element declarations} but to the actual components since the style MAY be dependent on direction or possibly sequence
What is a valid WSDL component model?
Primarily editorial issue
Relates to conformance section of the spec
TonyR: Need to correct "interprettion" -> "interpretation"
http://www.w3.org/2002/ws/desc/5/lc-issues/#LC357
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Nov/0001.html
Additional comments by Martin Duerst
Proposal w/b to add: "Note: The xs:anyURI type is defined so that xs:anyURI values are essentially IRIs [RFC 3987]. The conversion from xs:anyURI values to an actual URI is via an escaping procedure defined by [XLink 1.0], which is identical in most respects to IRI Section 3.1. (The only difference being that IRI defines handling of non-Unicode encoded byte sequences, considerations which do not affect this document directly.)"
[Reviewing comments from Martin Duerst]
For incompatibilities between URIs and IRIs, should we:
1) Allow the characters and specify escaping them
2) Only allow the subset of IRIs compatible with URIs?
3) Only allow some of the characters that are compatible across each layer
4) Apply 1-3 as appropriate/necessary
To resolve...
Add note plus a reference/list of constrained characters
Add the note, and the following: "For interoperability, authors are advised not to use these characters, which are allowed in IRIs, but not URIs."
<Jonathan_Marsh> My proposal:
<Jonathan_Marsh> Note: The xs:anyURI type is defined so that xs:anyURI values are essentially IRIs [RFC 3987]. The conversion from xs:anyURI values to an actual URI is via an escaping procedure defined by [XLink 1.0], which is identical in most respects to IRI Section 3.1. For interoperability, WSDL authors are advised to avoid the characters "<", ">", '"', space,
<Jonathan_Marsh> "{", "}", "|", "\", "^", and "`"
<Jonathan_Marsh> , which are allowed by the xs:anyURI type but disallowed in IRIs.
And action to take this to the CG
LC357 proposal - Jonathan's proposal above
<Jonathan_Marsh> ACTION: Marsh to take the IRI issue to the CG. [recorded in http://www.w3.org/2005/11/10-ws-desc-minutes.html#action03]
break for 15 minutes (15.35 JST)
Back from break
Close LC360
<Jonathan_Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Nov/0017.html
Arthur's proposal
Marsh: Best practices, not a
prescription
... Modulo minor editorial issues, is this a reasonably correct
addition to the spec?
[LC361]
<scribe> Closed
http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC362
Jacek: This is an editorial change....
<JacekK> as long as the component model is not affected
Marsh: Options: 1) Close with no action, 2) Arthur's proposal, 3) Jacek's proposal
Arthur: Friendly amendment to Jacek's proposal to include URIs for MEPs
<alewis> umit, i have two reactions: one is that everything else mostly has an IRI, the other is that we actually use those IRIs elsewhere in the spec.
<JacekK> the proposal, as I believe it is: add fault propagation rules IRIs, change MEP and op style IRIs to be spec references
<alewis> i'm fairly indifferent. i don't see this being terribly significant either way, and can live with any of the outcomes with no difficulty.
<umit> k
<alewis> so if someone else feels strongly enough, i can go with that.
<umit> i could not remember why we did not go down that path before since we discussed all this in the MEP tf a looong time ago
<alewis> umit, i don't recall that we discussed the issue of identifying fault propagation rulesets, and i didn't remember much discussion over the format of mep URIs (in fact, i don't think i remember any)
Poll
<Arthur> amy - do you have an opinion on uris for fault rules?
<alewis> i'm fine with whichever way.
Poll: Adopt Arthur's proposal: 8 YES 1 NO - Proposal accepted
Jonathan is off; Hugo taking over for chairing the rest of today's meeting
Glen to take an action to write a proposal to resolve this issue for tomorrow
Hugo: Only substantive issues
left: LC362 and LC333
... Adjourn until tomorrow
Jacek: Double binding of an operation issue
Discussion of this by the group
<hugo> http://www.w3.org/TR/2005/WD-rdf-sparql-protocol-20050914/#query-bindings-http
Hugo: The problem - we have a binding operation, and the same operation is bound twice.
Arthur: We know this to be illegal
Hugo: We need to write to the Data Access WG, adding a comment toward this
Paul formally apologises for this :-D
<Arthur> The SPARQL example violates Section 2.11.1: For each Binding Operation component in the {binding operations} property of a Binding component, the {interface operation} property MUST be unique. That is, one cannot define multiple bindings for the same operation within a given Binding component.
<alewis> bye!
<scribe> ACTION: Glen to write a proposal toward LC362 [recorded in http://www.w3.org/2005/11/10-ws-desc-minutes.html#action04]
<scribe> ACTION: Paul write to the DAWG re: binding operation twice [recorded in http://www.w3.org/2005/11/10-ws-desc-minutes.html#action05]
Hugo: Now we can really adjourn
<Arthur> The correct way to describe that service is with two bindings: one for GET and one for POST.
<hugo> Chair: Jonathan Marsh, Hugo Haas