W3C

WSD WG F2F, Mountain View, 2005-04-22

22 Apr 2005

Agenda

See also: IRC log

Attendees

Present
Rebecca Bergersen, IONA Technologies
Allen Brookes, Rogue Wave Software
Roberto Chinnici, Sun Microsystems
Glen Daniels, Sonic Software
Paul Downey, British Telecommunications
Hugo Haas, W3C
Tom Jordahl, Macromedia
Anish Karmarkar, Oracle
Amelia Lewis, TIBCO
Kevin Canyang Liu, SAP
Jeff Mischkinsky, Oracle
David Orchard, BEA Systems
Tony Rogers, Computer Associates
Arthur Ryman, IBM
Asir Vedamuthu, webMethods
Umit Yalcinalp, SAP
Observers
Heidi Buelow (Rogue Wave)
Phone
Ugo Corda, SeeBeyond
Youenn Fablet, Canon
Dale Moberg, Cyclone Commerce
Jean-Jacques Moreau, Canon
Bijan Parsia, University of Maryland MIND Lab
Regrets
Charlton Barreto, webMethods
Jacek Kopecky, DERI Innsbruck at the Leopold-Franzens-Universitšt Innsbruck, Austria
Chair
Marsh
Scribe
alewis, Arthur

Contents


<Marsh> chad, hi

<Arthur> Scribe: Arthur

Date: 22 April 2005

Jonathan: Defer DaveO's topic and MEPs

<Marsh> http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75g

Issue LC75g: RPC should allow element wildcards

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Mar/0038.html

Roberto: This is a versioning issue. It is useful to specify a wildcard as the last argument to you can add more parameters in a future version.
... This could apply to both request and response.
... My email looks at several popular programming languages, and they allow this.
... This affects the mapping to a function signature - last arguments is "varargs".
... I am not recommending this for response since most languages don't support it.

Paul: What is the semantics of the extra arguments if you receive them? Do you ignore them?

Jonathan: The schema says there is a wildcard at the end of the message, so the receiver needs to handle them.

RESOLUTION: Adopt Roberto's proposal.

Issue LC75f: RPC Allow extension attributes on RPC local element

See http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75f

Jonathan: The spec does not prevent attributes on local elements.

RESOLUTION: The spec is clear enough. Close with no action.

Issue LC118: New Issue RPC Style (and proposed fix)

See http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC118

RESOLUTION: Close the issue by accepting the proposal.

WS-Addressing and WSDL 1.1

Jonathan: This topic arose in the WS-Addressing F2F this week.

Hugo: Our schedule slip has impacted other WGs - WS-Choreography and WS-Addressing.
... WSA has a WSDL binding deliverable.
... WSA will split the WSDL into 2 documents: WSDL 1.1 and WSDL 2.0.
... If we publish a combined WSA spec then WSDL 1.1 is treated as for use to achieve backward compatibility.

Anish: Does the WSDL 1.1 binding have to be a Recommendation.

Jonathan: That is not the question for this group.

Hugo: All the options are open.

<sanjiva> I'm surprised the WSA groups is going to publish something about WSDL 1.1; when one of the guys working on Axis2's WS-Addr stuff asked about the submission MarkN jumped all over him and said "Don't ask questions about the submission on this list; contact the authors!". I guess different standards eh?

<sanjiva> I'd be ok with their doing a Note but certainly not a recommendation.

Jonathan: Would the WG like to communicate to WSA that they should keep the bindings together and treat WSDL 2.0 as the preferable solution.

<sanjiva> +1 from me!

<bijan> +1

<sanjiva> +1 to TomJ!!

<anish> sanjiva -- wsa's charter talks about publishing a rec with both wsdl 2.0 and wsdl 1.1 binding for backward compat

<sanjiva> Anish: Thanks; wish I had known that earlier so that I'd have had a nice colorful reply to MarkN's reply. Oh well.

<anish> :-)

<anish> i think, publishing wsdl 1.1 binding as a Note is the most practical solution (assuming that recharter if any would not be a problem)

Jeff: What can't the WSA Charter be changed so that the WSDL 1.1 binding is a Note?

Anish: Why was the WSA charter written that way?

Hugo: Both views were discussed by the charter was written (Rec versus Note for WSDL 1.1).
... W3C did not want a separate Rec for the WSA binding for WSDL 1.1 so we agreed to include it in the WSDL 2.0 Rec but marked as for backward compatibility.

Sanjiva: If they split the documents, can we raise an issue?

Hugo: This is a coordination issue. We don't have to issue a formal objection.
... There is a range of opinion.

Tom: WSA has an aggressive schedule so they won't wait for WSDL 2.0.

Sanjiva: The WSA binding is a separate document.

Anish: They need a binding to get out of CR.

<sanjiva> What I was saying is that the core *and* the *SOAP* bindings can go forward; just that the WSDL binding doc can hang around for us. That seems very prudent IMO.

Jonathan: They have a SOAP binding. Do they need a WSDL binding.

Hugo: Thx for input.
... W3C Team will make a recommendation.

MEP Issues

Jonathan: Some will depend on asynch task force.

Issue LC76a: MEPs should support addressing mechanism

See http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC76a

Amy: I'm sure sure how to change this. Factoring out faults reduced the number of MEPs.
... You may need to define a new MEP to change how the faults are delivered.
... We could potentially rephrase the fault rule sets to state which channels for fault delivery are expected to exist.
... We could leave the destination of the fault open.
... Extensions and bindings can change the semantics of MEPs.
... For example, WSA can override the MEP using Reply-To
... We could add a note to each MEP that says the destination may vary depending on the binding.

Glen: The MEP semantics should support code generation.

Tom: The wording Amy proposed sounds OK. "The fault is returned to the sender unless otherwise specified"

Amy: We could make an informative reference to WSA as an example of how to override the return destination.

Proposal: Add a clause to the fault rule set that says the destination of the fault may be modified by a binding or extension and to cite WSA as an informative example.

<Marsh> ACTION: Jonathan to ask WS-Addressing to ensure that they clearly specify overriding of the fault destination. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action02]

RESOLUTION: Close LC76a with the above resolution.

Media Type Description: Joe Fialli has three comments

See http://lists.w3.org/Archives/Member/w3c-ws-desc/2005Mar/0017.html

<Marsh> TonyR's proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0149.html

There are 3 proposals to resolve this: Tony, Roberto, Glen.

<Marsh> Roberto's: http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0146.html

<Marsh> Anish: http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0140.html

<Marsh> chad, new poll

<chad> new poll

<Marsh> Chad, which proposal should we adopt to address Joe's issue?

<Marsh> Chad, Question: which proposal should we adopt to address Joe's issue?

<Marsh> Chad: Option 1: Anish's

<Marsh> Chad: Option 2: Roberto's

<Marsh> Chad: Option 3: Tony's

<GlenD> friendly amendment to Anish's - s/achieve maximum interoperability with these tools/allow these tools to use their preferred optimal static binding/

<Marsh> Chad: Option 4: Glen's

<hugo> vote: 4, 1, 3, 2

<anish> chad: abstain

<Allen> vote: 2,4

<TomJ> vote: 3

<TonyR> vote: 3

<jeffm> vote: 3

<bijan> vote: abstain

<RebeccaB> vote: abstain

<alewis> vote: 3, 4

vote: abstain

<asir> vote: 3

<KevinL> vote: 3

<Roberto> vote: 2, 3

<Marsh> vote: 4, 1, 3, 2

<uyalcina> vote 3, 2

<uyalcina> vote: 3, 2

<GlenD> vote: 4, 3

<youenn> chad abstain

<alewis> chad, list voters

<youenn> *chad: abstain

<anish> vote: 3, 4

<pauld> vote: abstain

<Marsh> chad, count

<chad> Question: which proposal should we adopt to address Joe's issue?

<chad> Option 1: Anish's (0)

<chad> Option 2: Roberto's (2)

<chad> Option 3: Tony's (8)

<chad> Option 4: Glen's (3)

<chad> 17 voters: alewis (3, 4) , Allen (2, 4) , anish (3, 4) , Arthur () , asir (3) , bijan () , GlenD (4, 3) , hugo (4, 1, 3, 2) , jeffm (3) , KevinL (3) , Marsh (4, 1, 3, 2) , pauld () , RebeccaB () , Roberto (2, 3) , TomJ (3) , TonyR (3) , uyalcina (3, 2)

<chad> Round 1: Count of first place rankings.

<chad> Candidate 3 is elected.

<chad> Winner is option 3 - Tony's

RESOLUTION: Accept Tony's proposal.

Jonathan: Are there any unresolved issues that prevent the publication of the media type spec?
... Are they any objections to publishing it?

Anish: Did XMLP reply?

Jonathan: Yes, positively.

RESOLUTION: Publish it! Our first deliverable!!!!

Spontaneous ovation follows...

Break at 10:25AM

Resume at 10:40AM

Resuming meeting

Issue LC54: WSDL Last Call issue

See http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC54

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0122.html

DaveO is absent

Issue LC59e: Clarify serialization

See http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC59e

Proposal: Close with no action.

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0122.html

RESOLTION: Close LC59e with no action.

Issue LC54: WSDL Last Call issue

DaveO: The proposal shows an attribute @compatibleWith which can be either an extension or part of WSDL

Tom: Sounds like a proposal that was previously rejected by the WG

DaveO: That proposal dealt with versions of the WSDL document as a whole. This proposal focuses on the Service and optional an Endpoint of it.
... You may evolve a Service by extending an Interface or adding Bindings (at new Endpoints).
... This attribute says that an existing client can continue to interact with the new Service.

Glen: Does this involve changing the QNames of the Interface or Binding?

DaveO: No, just the Service.

Glen: Why would you rename the Service?

DaveO: Maybe the namespace has changed.

Arthur: You cited interface extension and new endpoints, which could be infered from the WSDL. Are there other cases that would require this attribute?

DaveO: I'm not sure we guarantee compatibility. The attributes asserts it.

Asir: The proposal is predicated on a versioning use case that involves introducing new QNames when the components change.

Anish: WebMethods is experimenting with a solution that makes versioning and compatibility information external to WSDL.

c/Asir/Asir/

Asir: WebMethods is experimenting with a solution that makes versioning and compatibility information
... How is this proposal valuable to a deployed client?

Glen: It applies to new clients.

Umit: You may need to regenerate stubs for a new WSDL.

DaveO: This proposal lets you know that your old clients still work so no regeneration is required.

Jeff: What can you say as being compatible? Can you change signatures?

DaveO: The definition of compatible is the issue. You can change whatever you want as long as an old client still works.

Jeff: We need to precisely define what it means for one service to be a version of or compatible with another service.

DaveO: I have enumerated the permissible changes, but objections were raised that this encroached an semantics or choregraphy.

Glen: I agree with Jeff. This space is not clearly defined. We do provide mechanisms, e.g. extension, that let services evolve in compatible ways.
... I am reluctant to use the groups time to put this in the spec now since this could be handled as an extension.

DaveO: Are you saying this work should be done outside the group?

Glen: No, but we need to find the current spec first.

DaveO: This is the second version of WSDL and I am not sure customer will want a third version or an extension to solve the versioning problem.

Glen: As I stated, by already have some mechanisms to evolve services.

DaveO: That view is too narrow. I'm looking at the situation where there are many services and some change in compatible ways.

Glen: We need to make tradeoffs now. This is a lower priority IMHO since there are other ways to accomplish this.

Umit: I agree with Jeff. e.g. look at RPC. We could do a better job to define compatibility there. If we did that, we would be in a better position to define service compatibility.

Arthur: The proposal is that the service provider is asserting that the new service won't break clients. You don't have to go deeper than that. This is a cheap and possibly valuable piece of information.

Roberto: It doesn't go far enough.

Tom: +1.

Umit: You need to be more specific about the interactions.

Tom: Isn't that what "Old clients won't break" means.

Jonathan: What are the options: return to proposer for more detail, staus quo, close with no action.

<asir> + 1 to poll now

<Marsh> chad: new poll

<chad> new poll

Tony: I find the proposal OK as written.

<Marsh> chad, option 1: Close issue no action

Asir: I remind the group we need to get to last call.

<Marsh> chad, option 2: Return proposal to author for additional development.

<asir> vote: 1

<dorchard> vote: 2

<KevinL> vote: 1

<Allen> vote: 1

<hugo> vote: 1

<Tomj> vote: 1

<jeffm> vote: 1

2

<RebeccaB> vote: 1

vote: 2

<TonyR> vote: 1, 2

<anish> vote: 1

<ugo> vote: 1

<uyalcina> vote: 1, 2

<Roberto> vote: 1

<Marsh> vote: 1

<alewis> vote: 1

<youenn> vote: 1

<Marsh> chad, count

<chad> Question: unknown

<chad> Option 1: Close issue no action (15)

<chad> Option 2: Return proposal to author for additional development. (2)

<chad> 17 voters: alewis (1) , Allen (1) , anish (1) , Arthur (2) , asir (1) , dorchard (2) , hugo (1) , jeffm (1) , KevinL (1) , Marsh (1) , RebeccaB (1) , Roberto (1) , Tomj (1) , TonyR (1, 2) , ugo (1) , uyalcina (1, 2) , youenn (1)

<chad> Round 1: Count of first place rankings.

<chad> Candidate 1 is elected.

<chad> Winner is option 1 - Close issue no action

Jonathan: Any objection to closing it with no action?

DaveO: Yes.

Jonathan: We'll do a formal vote.

Web Method: 1

<youenn> option 1 for Canon

IONA: 1

Rogue Wave: 1

Sonic: 1

Sun: 1

BT: absent

Canon: 1

Microsoft: 1

W3C: 1

Macromedia: 1

Oracle: 1

TIBCO: 1

SAP: 1

Cyclone: 1

BEA: 2

CA: abstain

IBM: 2

UMD: absent

BT: abstain

RESOLUTION: Close LC54 with no action.

Issue LC77a: Namespaced elements and urlformencoded

Jonathan: We have several options.

See http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC77a

<Marsh> DaveO's enumeration of options: http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0142.html

DaveO: I have collected all the alternatives into one message

Hugo: My original proposal doesn't work.

Asir: Which proposal are you talking about?

Hugo: Option 5 - use prefix in document, which unfortunately may not be unique

Jonathon: option 5 or 6 will need some additional work

Roberto: DaveO, can you reduce the list by eliminating some that you proposed?

DaveO: I don't like some, but I was asked to list all possible solutions. I like option 6 since it is more compact

Roberto: 1 is broken, 2 is broken, 2a, 2b, 2c work, 3 is evil, 4 works, 5, works, 6 works
... I prefer 2a, 2b, 2c

DaveO: Why do you object to serializing the namespace

Roberto: So your proposal eliminates prefixes

Paul: Please clarify option 4.

Jonathan: At present we say the children are local elements, but that doesn't disallow QNames. We could require unqualified names for the children

Hugo: We should either do it right or prevent people from using namespaces

DaveO: Is we at least allow one namespace we can binding the same operation to both HTPP and SOAP.

Hugo: 4, 2b or 6 work for me

Asir: I like 4. No HTTP GET implementations understand namespaces.

<Marsh> chad: Question LC77a Proposals

<Marsh> chad: Option 1: Status quo (broken?) (DaveO)

<Marsh> chad: Option 2: Ignore namespace prefix (DaveO)

<Marsh> chad: Option 2a: Require unique localNames (JM)

<Marsh> chad: Option 2b: Require single namespace

<Marsh> chad: Option 2c: Require names to be uniquely mappable to Qnames

<Marsh> chad: Option 3: Serialize QName (DaveO)

<Marsh> chad: Option 4: Disallow qualified elements (Asir)]

<Marsh> chad: Option 5: Serialize namespace names (Hugo, DaveO)

<Marsh> chad: Option 6: Ignore namespace prefix if single namespace, else serialize with namespace name (DaveO)

<Marsh> chad: Question: LC77a Proposals

DaveO: Why do people like 4? The goal of interfaces is to make the same operations available in different bindings.
... Option 4 makes interfaces tied to bindings.

Paul: HTTP GET is less flexible than SOAP

<asir> i don't know how someone would use uri style for JMS binding

Amy: You can design an interface that works for both HTTP GET and SOAP.
... Serializing the namespaces with result in long URLs which may exceed limits

DaveO: That's an urban myth (URL size limit)

<Allen> vote: 6

<dorchard> vote: 6

Asir: I think uri-style is what ties the interface to a binding, not option 4

<asir> vote: 4, 2b, 2

<alewis> vote: 4, 2b

<RebeccaB> vote: 6

<youenn> vote: 2b, 4

vote: 5, 6

<TonyR> vote: 6, 2b, 5

<pauld> vote: 4, 6

<anish> vote: 2b, 4

<bijan> vote: abstain

<Marsh> vote: 2b, 2a, 2c, 4, 6

<Roberto> vote: 2c,2b,4,5,6

<hugo> vote: 6, 5, 2b, 4

<GlenD> vote: 2b, 4

<Tomj> vote: 1

<dorchard> vote 6,2b

<dorchard> vote: 6,2b

<uyalcina> vote: 4, 2b, 6, 5

<KevinL> vote: 6,2b

<alewis> chad, list voters

<RebeccaB> vote: 6,5

<uyalcina> vote: 4, 2c, 6, 5

<Marsh> chad, list options

<Marsh> chad, new poll

<chad> new poll

<Marsh> chad: Question: LC77a Proposals

<Marsh> chad: Option 1: Status quo (broken?) (DaveO)

<Marsh> chad: Option 2: Ignore namespace prefix (DaveO)

<Marsh> chad: Option 2a: Require unique localNames (JM)

<Marsh> chad: Option 2b: Require single namespace

<Marsh> chad: Option 2c: Require names to be uniquely mappable to Qnames

<Marsh> chad: Option 3: Serialize QName (DaveO)

<dorchard> vote: 6,2b

<Marsh> chad: Option 4: Disallow qualified elements (Asir)]

<Marsh> chad: Option 5: Serialize namespace names (Hugo, DaveO)

<hugo> vote: 6, 5, 2b, 4

<Marsh> chad: Option 6: Ignore namespace prefix if single namespace, else serialize with namespace name (DaveO)

<asir> vote: 4, 2b, 2

<Allen> vote: 6

<dorchard> vote: 6,2b

<Marsh> vote: 2b, 2a, 2c, 4, 6

<TonyR> vote: 6, 5, 2b, 4

<KevinL> vote: 6, 2b

<RebeccaB> vote: 6,5

<youenn> vote: 2b,4,6

<alewis> vote: 4, 2b

<anish> vote: 2b, 4

<asir> vote: 4, 2b, 2

<GlenD> vote: 2b, 4

<pauld> tomj: http://www.xml.com/pub/a/2005/04/13/namespace-uris.html

vote: 5, 6, 2b

<pauld> vote: 4, 6

<Roberto> vote: 2c,2b,4,5,6

<uyalcina> vote: 4, 2c, 2b, 6, 5

<alewis> chad, list options

<jjm> vote: 2b, 4, 6

<Tomj> vote: 2b, l6

<dmoberg> vote: 6,5

<Tomj> vote: 2b, 6

<alewis> chad, list voters

<Marsh> chad, count

<chad> Question: LC77a Proposals

<chad> Option 1: Status quo (broken?) (DaveO) (0)

<chad> Option 2: Ignore namespace prefix (DaveO) (0)

<chad> Option 2a: Require unique localNames (JM) (0)

<chad> Option 2b: Require single namespace (6)

<chad> Option 2c: Require names to be uniquely mappable to Qnames (1)

<chad> Option 3: Serialize QName (DaveO) (0)

<chad> Option 4: Disallow qualified elements (Asir)] (4)

<chad> Option 5: Serialize namespace names (Hugo, DaveO) (1)

<chad> Option 6: Ignore namespace prefix if single namespace, else serialize with namespace name (DaveO) (7)

<chad> 19 voters: alewis (4, 2b) , Allen (6) , anish (2b, 4) , Arthur (5, 6, 2b) , asir (4, 2b, 2) , dmoberg (6, 5) , dorchard (6, 2b) , GlenD (2b, 4) , hugo (6, 5, 2b, 4) , jjm (2b, 4, 6) , KevinL (6, 2b) , Marsh (2b, 2a, 2c, 4, 6) , pauld (4, 6) , RebeccaB (6, 5) , Roberto (2c, 2b, 4, 5, 6) , Tomj (2b, 6) , TonyR (6, 5, 2b, 4) , uyalcina (4, 2c, 2b, 6, 5) , youenn (2b, 4, 6)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: First elimination round.

<chad> Eliminating candidadates without any votes.

<chad> Eliminating candidate 1.

<chad> Eliminating candidate 2.

<chad> Eliminating candidate 2a.

<chad> Eliminating candidate 3.

<chad> Round 3: Tie when choosing candidate to eliminate.

<chad> Tie at round 2 between 2c, 5.

<chad> Tie at round 1 between 2c, 5.

<chad> Tie broken randomly.

<chad> Eliminating candidate 2c.

<chad> Round 4: Eliminating candidate 5.

<chad> Round 5: Eliminating candidate 4.

<chad> Candidate 2b is elected.

<chad> Winner is option 2b - Require single namespace

<alewis> chad, details

Jonathan: Who can't live with 2b?
... no one.
... Who can't live with 6?
... no one

Roberto: In option 6, how do I determine if there is one namespace?

DaveO; that can be determined from the schema

DaveO: however, extensibility might break that since you would allow other namespaces, which you wouldn't know until runtime

Asir: Actually, 2a is the status quo

Anish: Why did those people who voted for 6, not vote for 5?

DaveO: Because 6 allows for an optimization of the single namespace case, you don't have to serialize namespaces then

Umit: Asir made a good observation, so since local names must be unique, we don't have to serialize namespaces

The status quo is that the local names must be unique to there is no need to serialize the namespaces

Glen: Do we need to clarify the spec?

Hugo: Maybe an example will make this clear.

DaveO: I can update the Primer examples using the status quo, and then look at the examples and decide if we are happy.

Asir: I suggest we close now and let someone else reopen if the status quo is unacceptable

Jonathan: I propose to close this issue with an editorial clarification of the status quo.
... Any objections?

RESOLUTION: Close LC77a with editorial clarification.

Break for lunch at 12:22 PM. Resume in 45 minutes.

<asir> Paul's urlformencoded pix http://www.flickr.com/photos/psd/

LC59f

Glen: we can not do anything with this objection right now.

Anish: Is the compromised proposal in the agenda?

Marsh: We can take the proposal to the formal objectors.
... We note that there are formal objections, and we will notify them.

RESOLUTION: Close the issue. Handle it procedurally.

LC89d

Discussion about the current semantics...

Glen: Something is a contraint at the interface level, everything inside has to follow the contraint.
... Only narrowing allowed, you can not change

Anish: What is the defn of narrow?

<asir> in section, 2.7.1.1 - If a given feature is asserted at multiple locations, then the value of that feature at a particular component is that given by the nearest assertion in lexical scoping order.

Glen: Look at it two ways.

Glen 1. There is no way to shut it off in the interface

Anish: I can come up with another feature and disable the first feature

Amy: agrees with Anish

Glen: With properties, it does not make any sense to state a different property value at the lower level which is set at the interface level.

<asir> in section 2.8.1.1 - "If a given property is asserted at multiple locations, then the value of that property at a particular component is that given by the nearest assertion in lexical scoping order."

Glen: 2. You are specifying a default at a particular level and you can override it in lower levels.
... This interpretation removes the interpretation that it sets a contraint. It becomes a default now instead of a contraint.

umit: notes that the two semantics are equivalent.

Glen: disagrees

Asir: We have asked this question many times and got different answers. Look at LC27.
... We talk about intersections there.

Glen: We are not allowing the feature requested by design.

Marsh: Any objections to closing the issue with no change?

No objection

RESOLUTION: Close with no action

LC89e

Amy: You can attach F&P to an endpoint.

Marsh: Logical conclusion here in this issue that we should not specify endpoint specific information in WSDL

Discussion goes on about what is meant by runtime specific instance by the issuer.

Amy: He is saying that properties does not belong to WSDL.

Glen: We specify the value constraint which is different than the actual value with properties.

<Marsh> http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89e

<scribe> ACTION: Glen to send a response for LC89e [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action03]

RESOLUTION: Close the issue.

LC75m

Arthur: This is done and already fixed.

RESOLUTION: Close the issue.

LC89f

Amy: We are producing a test suite. We have conformance characteristics. We should reject this.

Marsh: Usually there is a profile in scope. It is not clear whether it is our place to provide that.

Arthur: Is this about component model?

Marsh: He is asking about a specific profile (XML version) in our document.

Arthur: We have strengthened that section.

Marsh: Editorial Collapse Section 8 and call it Infoset conformance.

Amy: Suggestion: The component model must be expressable with XML 1.0.

Marsh: We don't support XML 1.1 values in our properties.

Amy: This should be expressed explicitly.

<anish> here is the text that is used in MTOM:

<anish> "Any W3C recommendation-level version of XML is allowed for storing the XOP Infoset created from the SOAP envelope Infoset into the MIME Multipart/Related XOP Package, however, note that the SOAP envelope Infoset MUST be serializable as XML 1.0."

Discussion goes on interpreting whether Rich's issue is about serialization...

Amy: He is not asking for the serialization. We have dealt with this in Boston and rejected his point. This is a follow up. We are not accepting the proposal to drop the component model and infoset terminology.

I propose the following statement: An XML 1.0 document that is valid with respect to the WSDL 2.0 XML Schema and that maps to a valid WSDL 2.0 Component Model is conformant to the WSDL 2.0 specification.

Proposal: Close with no action
... Add Arthur's proposal

Amy: Not all contraints are expressable in XML Schema.

Arthur: It does not hurt to state this.

Marsh: Poll to accept Arthur's proposal

13 in favor

Marsh: No objections.

<jjm> +1

RESOLUTION: Close the issue by adopting Arthur's proposal

LC110

TomJ: Point to the RFC and we are done

Amy: The diff is that there is a "/"

Paul: Our major or minor does not cover the httpr, etc.

Hugo: Our default value is 1.1. RFC2616, etc. But the HTTP spec has versioning scheme as well.

Asir: We use namespace name in SOAP.

MArsh: Proposal 1: Status Quo.

<hugo> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.1

Proposal 2: Restrict the pattern digit.digit.

Proposal 3: RFC2616

Marsh: You always have to type "http" in Proposal 3

<hugo> HTTPR does: HTTPR/1.0 (I wonder how that relates to RFC2616)

<jjm> 3 is necessary for HTTP serialization, but overkill for WSDL

Umit: Propose to use 3 with the restriction, ignore "HTTP/". Similar to the method used in media-types accept strings.

<jjm> isn't that 2?

It is a friendly amendement

<JacekK> how about a proposal: default not "1.1" but "HTTP/1.1", but leave it xs:string to accommodate HTTPR

Proposal 2: REstrict the pattern, digits.digits Add an explicit ref to 2616

Amy objections?

No objections noted.

Mr. Akitoshi Yoshida

RESOLUTION: Accept Proposal 2: Restrict the pattern digits.digits. Add an explicit ref to 2616

LC76b

<scribe> ACTION: Amy to define propogation [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action04]

LC62a

Asir: 62a and 63b are related. I am combining them for my question.
... In Part 1 address is optional. At London f2f, WG188 issue was resolved and address was added to the endpoint. At the meeting, it became optional.
... Why?

Amy: Not everything is addressable.
... With JMS, URIs are not usable. There is no URI scheme for it. What requires JNDI and JNDI URL and properties.
... Either use a bogus URI, empty URI or make it optional for those bindings where URIs are not sufficient.

Anish: Transport is proprietary and you may be able to come up with a scheme, make it up.

Marsh: We can leave off the element and use an extension instead.

TomJ: Not really correct for most common bindings.

TomJ and Amy discuss whether the address is necessary or can be omitted for JMS like cases.

<xs:attribute name='address' type='xs:anyURI' use='optional' />

Arthur: Simple fix is one liner. Put it in the schema and has been for the test suite.

Paul: You want to leave the address although you may be willing to policy in the endpoint. You want to publish WSDLs without an address.

TomJ: There are usecases, but they are not in 80/20.

Arthur: Status quo is that it is optional.

TomJ: Proposes to make it mandatory.

Kevin: Can we justify why it is optional in the spec?

TomJ: Insists that majority use case is where there is an actual address and therefore it should be mandatory
... Proposes a specific URI to designate other cases

<pauld> VOTEVOTEVOTE

<Marsh> chad: new poll

<chad> new poll

<Marsh> Chad: Question: LC62b resolutions

<Marsh> Chad: Option 0: status quo

<Marsh> Chad: Option 1: Make @address mandatory

<Marsh> Chad: Option 2: Make @address mandatory + predefine an "specified elsewhere" URI.

<alewis> vote: 0

<RebeccaB> vote: 0

<Allen> vote: 0

<Marsh> vote: 0

<Roberto> vote: 0

<pauld> vote: 0

vote: 0, 2

<pauld> vote: 0,0,0,0,0,

<anish> vote:1, 0

<pauld> vote: 0

<asir> vote: 0

<jjm> vote: 0

<TomJ> vote: 2,3

<KevinL> vote: 0,2

<anish> vote: tom: 2, 3

<TomJ> vote:1,2

vote: 0

<alewis> chad, list voters

<pauld> vote: tomj: 0

<TomJ> vote: 1,2

<TonyR> vote: abstain

<jeffm> vote: 1,0

<hugo> vote: 0, 2, 1

<Marsh> chad, count

<chad> Question: LC62b resolutions

<chad> Option 0: status quo (13)

<chad> Option 1: Make @address mandatory (3)

<chad> Option 2: Make @address mandatory + predefine an "specified elsewhere" URI. (0)

<chad> 17 voters: alewis (0) , Allen (0) , anish (1, 0) , Arthur (0) , asir (0) , hugo (0, 2, 1) , jeffm (1, 0) , jjm (0) , KevinL (0, 2) , Marsh (0) , pauld (0) , RebeccaB (0) , Roberto (0) , scribe (0, 2) , TomJ (1, 2) , tomj (0) , TonyR ()

<chad> Round 1: Count of first place rankings.

<chad> Candidate 0 is elected.

<chad> Winner is option 0 - status quo

Marsh: Propose to clarify that it is optional for the use cases of extensibility.

Amy: Our bindings do not require it either

Paul: The other use case is deployment flexibility with policies

Amy: HTTP binding may require the address.

Marsh: What is the difference for Paul's use case/

Paul: Another use case is for consortiums. Gold service, test service etc. that are same interface, binding where you don't have the control of the definition as you require them from the consortium. You want to supply the address in addition.

Marsh: We put a clarification to the spec why it is optional and state that it is intentional. Action to someone to examine HTTP binding and whether the same argument applies.
... Any objections?
... No objection.

RESOLUTION: Optional on purpose. Close the issue 62a by fixing the schema. Editorial fix to clarify the specification why it is optional intentionally.

<scribe> ACTION: Hugo to investigate HTTP binding and determine whether address is optional. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action05]

LC89a

<Marsh> http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89a

Marsh: this looks like a duplicate

Roberto: We need to be more specific about the conformance in our bindings.

<uyalcina> Proposed Resolution: Add a conformance to the RPC extension.

MArsh: Objections? None noted.

RESOLUTION: Close issue with Action to editors.

<scribe> ACTION: Editors to add a conformance for rpc extension. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action06]

LC89h

<Marsh> http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89h

Amy: This is similar to an objection raised by BEA. It is a duplicate.

Marsh: Part of the issue is the criticism for the pseudo schema.

<TomJ> I disagree that removing the psudo-schema and infoset description will make anything more clear

Arthur: BNF is used in XML. We are using a similar mechanism.

<jjm> +1

Amy: BNF describes the structure of XML. We are describing Infoset items.

The only viable alternative is to use RelaxNG.

Marsh: The comment is that we can use the complexity by getting off the pseudo schema and infoset and replace by XML schema.

Amy: This is painful.

TomJ: Proposes to close with no action with the rationale that it would make it harder to read the spec.

RESOLUTION: Close with no action.

LC100

<Marsh> http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC100

<asir> http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jan/0006.html

Asir: Arthur has a proposal.

Arthur: The structure of WSL doc has three sections and they must follow the order.
... However we can not enforce the order as we allow other namespaces.
... The schema can not dictate the order as a consequence.
... Proposes two additional top level elements, one for imports and one for component definitions.
... Solves the issue. Preludes, types, components are the sections.
... Those new ones are optional.

http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jan/0006.html

Amy: agrees that it is undeterministic.

<description>

<pauld> sounds like COBOL: DATA DIVISION ENVIRONMENT DIVISION PROCEDURE DIVISION

<pauld> schema can't describe our XML, so we have to change out XML .. big sigh :o(

Asir: We should not introduce these additional wrappers just to solve this problem.

Amy: Agrees with Asir.

Arthur: We need additional contraints in the component model to solve this problem if we don't introduce them.

<TomJ> I really don't like the idea of adding new tags in to the WSDL syntax.

Amy: If we were to introduce substitution groups, which we did previously, we can end up with a deterministic content model but we explored this before.

Umit, Amy:The order is there for the forward declaration just like Schema

TomJ: This is a significant change, and users will not like it and our rationale.

<KevinL> +1 to Tom

Arthur: This is why we have a schema for putting constraints.

Amy: This is an artifact of XML Schema and we trip over it.

Umit: Aren't there any other contraints structurally in addition to this? Why is this the only problem?

Asir: They are other contraints we can not express.

Arthur: Structural order is a key strength of XML Schema.

Amy: Expresses her dislike for the new proposed structural delimiters...
... We want to specify an order in the spec.

<alewis> chad, new poll

<chad> new poll

TomJ: Proposes to close with no action

<alewis> chad, question: close all remaining issues with no action

<alewis> chad, option 0: yes, close with no action

<asir> vote: 0

<alewis> chad, option 1: no, close taking no action

<asir> vote: 0, 1

<TonyR> vote:5

<TonyR> vote:5, 4, 3, 2001, 42

RESOLUTION: Close with no action.

<alewis> chad, new poll

<chad> new poll

LC117

http://www.w3.org/2002/ws/desc/4/lc-issues/#LC117

Arthur: Propose to fix the problem by making endpoints as not endpoint qualified. Or make all our elements not element qualified except top elements.

Amy: This is a general problem. My reservation is that we will see many complaints wrt validation.

<Roberto> +1 to Amy's statement

Arthur: For WSDL, there are very small number of elements that need to be qualified.

Glen: There is practice to make use of global elements for everything and references out there.
... It will take a while to understand for element form qualified means in the community.

Amy: Authors find that error messages less than comprehensive.

Marsh: Are there other solutions?

Glen: We can have a separate service refs.

+1

Arthur: It is a requirement we agreed on and requirement we agreed.

Glen: We have EPRs now.

Arthur: We still need static time marker.

<asir> arthur, what is the requirement # that you mentioned?

Umit: We may be able to use the EPR type and define two extensibility attributes.

Glen: Annotations can be used universally, either with types or with URI
... This allows us without nailing down the type we could use it for different representations.

Arthur: Decide on whether the Schema fix is viable first.

Glen, Umit: We can do this genericly by two design time annotations.

scribe: Globalize them like wsdlLocation

TomJ: Lets fix our solution first.

Marsh: This is not a requirement we need to fullfill as it was listed with a should.

Umit: Propose to put the solution in Part 2 in extensions.

Arthur: Rest style web services need a solution in this area.
... Rest uses URIs for references.

Marsh: What does the app do when it gets a reference?

Arthur: It is not a URI, but a known ref that you can use to communicate message exchanges with.

TomJ: Why fixing the schema is not an option?

Marsh: Just fixing the endpoint element creates a confusion.
... I'd rather do a different solution.

TomJ: Want to bug fix, not rewrite it.

Amy: It is a rock and a hard place. Arthur says the spec is not complete.

Arthur: Rest apps are not interested in the full definition of service definitions, but URIs.
... Define an endpoint type and we can derive it.

TomJ: Not everything needs to support WS-Addressing

Anish: WS-Addressing did not accept the service defn. We are ignoring those

TomJ: Lets fix the problem.

Proposal: When you want to describe a message that sends a service reference, create an element that restricts wsdl:ServiceType and specifies a fixed value for the @interface attribute.

Glen: We have a solution where we do not have to bring the WS-Addressing into the section.

Paul: Umit is right. This is new information brought as WS-Addressing is now in the picture.

Proposal: Wne you want to describe a message that sends an endpoint reference, create an element that restricts wsdl:EndpointType and specifies a fixed value for the @binding attribute.
... The description can rely on the wire protocol. Prefer WSDL can depend on WS-Addressing rather WS-Addressing on WSD.
... You may also use other message formats to send service and endpoint references, e.g. WS-A.

Arthur: we use endpoint and service type as base types as a solution.

Umit: Define two extension attributes, but not require EPRs.

TomJ: I want to fix the problem. Asks why we can not use the current solution.

Arthur: This is a schema restriction, we can not restrict the endpoints in order to define the binding.
... Using the endpoint element fixes the bugs as an addition and fixes the bug.

TomJ: Likes the solution.

Amy: Designate someone in WS-Addressing as a person as a liason but not solve WS-Addressing issues here.

Hugo: We are trying to talk about EPR which is designed in WS-Addressing. They are solving the same problem.

Amy: Why can not our solution be offered to them?

Jeff, Umit: It has already been rejected.

Hugo: It is very confusing to have three different solutions.

Amy: I am crafting a response to WS-Addressing about this, and we should hear from them formally.

Hugo: Two option: We send a comment to WS-Addressing wg before May 11 asking why they are not using our solution
... Option 2: Evaluate their solution and give feedback why it is not suitable for us if there are concerns,

Roberto: Service Refs work for restricting the interface. But for Endpoint References, there are two types of WS.
... For SOAP everyone will use WS-Addressing. For HTTP, people will use the URI. We should not do anything there.

<Zakim> KevinL, you wanted to ask Arthur a question about endpoint type

+1 to Roberto.

Discussion continues as what an EPR is, what it contains, whether it contains multiple endpoint addresses, etc.

<TomJ> I would support Arthur's proposal to allow restriction of both service type and endpoint type

Arthur: For the REST community, a simpler solution is needed.

Umit: The schema derivation problem applies to both EPRs or Service Types. This is why attribute extensibility with two annotations is my preferred solution.

<asir> Arthur's proposal - Proposal: When you want to describe a message that sends an endpoint reference, create an element that restricts wsdl:EndpointType and specifies a fixed value for the @binding attribute.

Rebecca: Can you choose of the binding options ?

Arthur: You can restrict from an enumeration

Objections to adopting Arthur's proposal?

None noted.

Marsh: Addressing specifies an Endpoint Reference but does not provide restrictions on this structure.
... There is no restriction and what we are trying to do is to describe these restriction.

<Marsh> ACTION: Marsh to ask WS-A to review primer re: endpoint references, and to ask them for any advice about how to describe EPRs to the end of identifying which interface and/or binding are referenced just from examining the description. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action07]

<hugo> relationship to WS-Addressing; from the WS-Addressing charter: "[..] provides an XML format for exchanging endpoint references"

<scribe> ACTION: Umit to write an alternate proposal [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action08]

<scribe> ACTION: Editors to add Arthur's proposal to the spec [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action09]

LC52c

Roberto: Fault codes are not defaultable.

Marsh: Any objections to closing?

RESOLUTION: Closed by adding the clarification.

LC61c

Marsh: Propose to close with no action

Arthur: We don't have an example that illustrates the usage.

Amy: I can provide at least three.

Marsh: Add an example to the advanced topics in the primer.

Arthur: I want them in the test suite.

Marsh: Close the issue by explaining that this helps us to provide extended maps

RESOLUTION: Close the issue.

<scribe> ACTION: Amy to provide examples for the advanced section of the primer. Amy to send them to Kevin and test materials to Arthur. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action10]

LC64

<scribe> ACTION: Arthur to investigate the Schema Designators and come back with a proposal [recorded in http://www.w3.org/2005/04/23-ws-desc-minutes.html#action01]

LC71

Amy: This is an old issue.
... There is no new info.

Marsh: Is there any new information?
... Does anyone speak infavor?

LC72

Marsh: Propose to close with no action.

Proposal 2: Add clarification that some faults may come back.

TomJ: Clarification is in the spec.

No objections to close with no action.

RESOLUTION: Close with no action.

No resolution for LC71.

LC74b

No resolution noted.

LC74c

Marsh: We can say that we encourage you to use the xml:lang on the contents.

Amy: Propose to allow additional documentation element with xml:lang attribute.

<scribe> ACTION: Amy to investigate a solution [recorded in http://www.w3.org/2005/04/22-ws-desc-minutes.html#action02]

LC75c

LC75d

RESOLUTION: To accept the issue by changing "same type" to "same named type".

LC75o

Amy: Currently the schema requires at least one endpoint
... Given that we had a similar resolution, it is reasonable to allow this and change the spec.

Arthur: In other places we require it, why do it differently ?

Marsh: Push it to the stack.
... Meeting adjurned.

LC75p

Marsh Any objections to close it subsumed by LC62b?

Marsh: None recorded.

RESOLUTION: Close the issue.

<Marsh> chad, bye

Summary of Action Items

[NEW] ACTION: Amy to define propogation [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action04]
[NEW] ACTION: Amy to provide examples for the advanced section of the primer. Amy to send them to Kevin and test materials to Arthur. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action10]
[NEW] ACTION: Editors to add a conformance for rpc extension. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action06]
[NEW] ACTION: Editors to add Arthur's proposal to the spec [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action09]
[NEW] ACTION: Glen to send a response for LC89e [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action03]
[NEW] ACTION: Hugo to investigate HTTP binding and determine whether address is optional. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action05]
[NEW] ACTION: Jonathan to ask WS-Addressing to ensure that they clearly specify overriding of the fault destination. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action02]
[NEW] ACTION: Marsh to ask WS-A to review primer re: endpoint references, and to ask them for any advice about how to describe EPRs to the end of identifying which interface and/or binding are referenced just from examining the description. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action07]
[NEW] ACTION: Part 2 editors to define frag id extensions for soap:header, http:header, soap:module. [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action01]
[NEW] ACTION: Umit to write an alternate proposal [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action08]
[NEW] ACTION: Amy to investigate a solution [recorded in http://www.w3.org/2005/04/22-ws-desc-minutes.html#action02]
[NEW] ACTION: Arthur to investigate the Schema Designators and come back with a proposal [recorded in http://www.w3.org/2005/04/22-ws-desc-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.122 (CVS log)
$Date: 2005/03/31 04:43:41 $