See also: IRC log
<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
<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.
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.
See http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC118
RESOLUTION: Close the issue by accepting the proposal.
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.
Jonathan: Some will depend on asynch task force.
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.
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
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
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.
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.
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/
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.
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
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.
Arthur: This is done and already fixed.
RESOLUTION: Close the issue.
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
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
<scribe> ACTION: Amy to define propogation [recorded in http://www.w3.org/2005/04/21-ws-desc-minutes.html#action04]
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]
<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]
<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.
<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
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]
Roberto: Fault codes are not defaultable.
Marsh: Any objections to closing?
RESOLUTION: Closed by adding the clarification.
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]
<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]
Amy: This is an old issue.
... There is no new info.
Marsh: Is there any new
information?
... Does anyone speak infavor?
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.
No resolution noted.
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]
RESOLUTION: To accept the issue by changing "same type" to "same named type".
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.
Marsh Any objections to close it subsumed by LC62b?
Marsh: None recorded.
RESOLUTION: Close the issue.
<Marsh> chad, bye