- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 29 Oct 2004 14:35:15 -0700
- To: <www-ws-desc@w3.org>
Web Services Description Working Group;
2004-10-28 conference call minutes
Attendance:
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Ugo Corda SeeBeyond
Paul Downey British Telecommunications
Youenn Fablet Canon
Hugo Haas W3C
Anish Karmarkar Oracle
Jacek Kopecky DERI
Amy Lewis TIBCO
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Dale Moberg Cyclone Commerce
Jean-Jacques Moreau Canon
Bijan Parsia University of Maryland MIND Lab
Arthur Ryman IBM
Jerry Thrasher Lexmark
Asir Vedamuthu webMethods
Sanjiva Weerawarana IBM
Prasad Yendluri webMethods, Inc.
Regrets:
Helen Chen Agfa-Gevaert N. V.
Tom Jordahl Macromedia
David Orchard BEA Systems
William Vambenepe Hewlett-Packard
Agenda: http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0067.html
Scribe: Prasad Yendluri
------------------------------------------------------------------
2. Approval of minutes:
- Oct 21 [.1]
[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0066.html
Marsh: Any comments or questions?
Minutes Approved.
--------------------------------------------------------------------
3. Review of Action items [.1]. Editorial actions [.2].
PENDING 2004-04-01: Marsh will get schema tf going.
PENDING 2004-09-02: Bijan to create stylesheet to generate a
table of components and properties.
PENDING 2004-09-16: Editors to move App C to RDF Mapping spec,
except the frag-id which will move
within media-type reg appendix.
PENDING 2004-09-16: Editors to fix paragraph 6-9 of section
2.1.1 moved into 2.1.2
which talks about the syntax.
PENDING 2004-09-16: Hugo to get a URI to use for DTD example
in Appendix E.1 (LC38)
PENDING 2004-09-30: Arthur to add Z notation to Part 1.
PENDING 2004-10-07: Paul to set up test suite directory
structure (Hugo assist)
PENDING 2004-10-07: Primer editors to use the new
terms "Web service" and "consumer|client".
dbooth: Kevin and I are working to produce a full draft by Friday.
We have enough got done and I would like to get feedback from the WG
Marsh: Plan for a Working Draft?
dbooth: Hoping get done by tomorrow. But I like people to take a quick look today
and give feedback on how the approach is working out.
Marsh: Everybody try and do that.
PENDING 2004-10-14: Arthur to prototype a javascript
implementation and decide on the two doc's
vs javascript method later.
PENDING 2004-10-14: Editors to add a statement like:
The Style property may constrain both
input and output, however a particular
style may constrain in only one
direction. In Section 2.4.1.1 of Part 1.
(subsumed by LC21 resolution?)
PENDING 2004-10-21: Glen to respond to Tim Ewald re: LC9.
PENDING 2004-10-21: Hugo to generate a summary of pub options.
PENDING 2004-10-21: Roberto to list some non-fatal errors
for consideration if that's useful.
[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://www.w3.org/2002/ws/desc/4/lc-issues/actions.html
---------------------------------------------------------------------
4. Administrivia
a. November 9-11 (Sunnyvale, CA) registration [.1], logistics [.2]
b. Jan FTF?
c. Tech plenary?
[.1] http://www.w3.org/2002/09/wbs/34041/WSD0411/
[.2] http://www.w3.org/2002/ws/desc/4/04-11-f2f.htm
Marsh: Working with WS-Addressing group to have a joint meeting in Jan,
possibly in Australia
Sanjiva: Is Srilanka out again?
Marsh: No. There is a chance of getting critical mass if we co-host with
WS-Addr
Sanjiva: I will be happy to do it
Marsh: O.k. I will put that in
dbooth: I prefer not the week of Jan 12th
Marsh: We are talking the week after that
------------------------------------------------------------------
5. New (non-LC) Issues. Issues list [.1].
- none.
[.1]
http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.html
------------------------------------------------------------------
6. Last Call Issues [.1]. Comments list [.2]
- LC70 Pluggability of Schema Languages in WSDL [.3]
[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/
[.2] http://lists.w3.org/Archives/Public/public-ws-desc-comments/
[.3] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC70
Marsh: New LC issue from Asir on pluggability of schema languages
------------------------------------------------------------------
7. Media Type Description [.1] Last Call status
- publication update
[.1]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/media-types/xml-media-t
ypes.html?content-type=text/html;%20charset=utf-8
Marsh: We wanted input from the Schema WG on when they would like the
LC period to end. Just got the Nov 24th date from them. We can
fit that in and get that docs out today as the LC.
Marsh: Thanks to Anish and Hugo for the hard work on this
------------------------------------------------------------------
8. Issue LC5f: QA Review on WSDL 2.0 Part 1, intro and conformance
issues (f) [.1]
- Roberto's proposal [.2]
- Awaiting list of "errors" from Roberto.
[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC5f
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0027.html
Marsh: Skipping over. Waiting on mail from Roberto.
------------------------------------------------------------------
9. Issue LC29b: Review of WSDL 2.0 Pt 3 Last Call WD (b) [.1]
Issue LC18: Relationship between Features and SOAP Modules ?? [.2]
- Awaiting Glen's action
[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC29b
[.2] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC18
Marsh: Both issues are reg. lack of explicit relationship between
Features and Modules. Glen responded why. MarcH was satisfied
but Prasad had a further question.
Asir: Glen promised to do another write up, that talks about relation
bet. features and modules. Its in the last para. of his email.
He wants a new action item.
NEW ACTION: Glen to write up the relation between features and modules
Marsh: Prasad is your concern same?
Prasad: Same. Glen says we don't need to identify the Features in
the module. I was asking how you can deduce the features a
module supports if they are not identified.
Marsh: We will formalize Glen's write-up to formalize text that goes
into the spec
------------------------------------------------------------------
10. Issue LC29d: Review of WSDL 2.0 Pt 3 Last Call WD (d) [.1]
- DaveO's proposal [.2]
[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC29bd
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0061.html
Marsh: Skipping, DaveO not present.
------------------------------------------------------------------
11. Issue LC19: Fault Component Re-usable Across Interfaces [.1]
- Awaiting Asir's action to detail binding changes
[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC19
Asir: I did my action
http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0057.html
Asir: There are 4 changes:
1. Adding a new definition component faults
2. How operation fault reference ties to a fault in Definitions
faults property
3. How Binding Fault Component describes the concrete binding of
a fault to a concrete message format. How it points back to a
fault component in the Definitions faults property
4. Fault URI reference will change from x/y to x. x is the name
property of the fault.
Arthur: I like it as it treats them like exceptions in Java
Sanjiva: I have one concern about the binding. Two interfaces that use
the same fault would have to bind it twice. Which is redundant.
The bindings for the same fault in both would have to be same.
Otherwise code generation would break.
Asir: I don't understand the last part
Sanjiva: What if you define different fault codes and sub-codes for the
same fault in both bindings.
Asir: I think you are not allowed to do it.
Sanjiva: Today the problem does not exists as we keep faults as top level
children of the interface and binding
Asir: We have an explicit constraint in part 1.
Section 2.10.1: For each Binding Fault component in the {faults}
property of a Binding component, the {fault reference} property
MUST be unique. That is, one cannot define multiple bindings for
the same fault within a given Binding component.
Sanjiva: It is saying a different thing. You can not binding the same fault
to two different things in the same Binding component.
Sanjiva: What your proposal allows is to define two different fault-codes
for the same fault.
Asir: No it is not possible. That is why I mentioned the last para. in
section 2.10.1
Sanjiva: It is different. It is like section 2.11.1 for binding operation.
Asir: I am not getting the point.
Arthur: If a fault is reusable across interfaces, wouldn't you want to
bind the fault same way independent of an interface? If is
reusable, why would I bind it differently? Within a binding you
would also have to promote binding fault.
Asir: Fault is a property on the binding component
Sanjiva: But, in order to support first class top level faults, you need
to be able to say binding.fault is a QName. Otherwise you will
run into the issue of two different fault-codes
for the same fault.
Asir: I think you can raise this new issue
Sanjiva: Not a separate issue. I am not going to vote for it unless
this issue is resolved.
Arthur: If you really want to promote faults, you need to promote
bindings too.
Roberto: Did we already decide we are not going share fault by extending
fault interfaces? If someone is defining a system with multiple
interfaces that share faults, ... I don't see much value in
giving faults independent existence. This proposal is technically
correct with Sanjiva's amendment but, ..
Asir: Binding fault contains soap.fault code, subcode etc. If we promote
binding to definitions what is the meaning of what will be its
meaning outside the binding?
Sanjiva: It is not promoting biding fault component to top level. You
still have the notion binding. Except you are not binding an
interface but, you are binding a fault.
<binding interface="qname"> .. </binding>
<binding fault="qname"> ... </binding>
Sanjiva: Then we have a different problem. We will have to allow
composition of binding which we do not have now. To say, I
am binding this interface along with that fault-binding.
Asir: I understand what you are saying based on what you pasted in
IRC. Today interface has a subset of all possible faults. Binding
has subset (or all) of those faults and binding.operations ref.
a subset of those. So you have a subset of subset of subset. Based
on this I don't see a stronger relationship to put all the
fault-names in the binding mark-up. Regardless of how many
we have in the interface it does not fully describe them in the
binding.
Sanjiva: I don't think anything changes with regards to the faults being
an open set. The faults that service author feels important to
the clients are what are described. That is not complete list
of all the faults.
Asir: That is why I am saying the relation between interface and binding
is week. It is ok to be out side the interface.
Prasad: Don't we have the same issue that Sanjiva raises currently?
Two different bindings for the same interface could bind the
faults differently (different codes).
Sanjiva: Sure you can have SOAP 1.1 and SOAP 1.2 binding.
Prasad: You can also have two different SOAP 1.2 bindings for the same
interface. But, don't we currently have the same issue of binding
the faults in the same interface differently in two different
bindings?
Sanjiva: That is fine but, the whole point of this is to enable
reusability of bindings
Asir: The way the issue was raised is, reusability of fault component
across interfaces. We did not talk about bindings.
Sanjiva: To make faults top level. If you do that, the analogous thing
to do is, the ability to bind faults top level.
Prasad: I think there is difference in reuse of faults at the interface
level, different interfaces and operations and reuse at the
binding level. I think we want to be able to bind the same
fault differently based on the binding.
Arthur: The issue is how should the fault be modeled. In the programming
example case, interfaces and faults are modeled as classes. So
they are the same kind of things. That enables re-use.
However we are saying Fault is not like an interface. It is like
an operation. However as Roberto said, you can still achieve reuse
by define an interface with a set of faults and re-use them.
You can do that and keep the current component model or if you
change the component model to elevate the faults to top level,
our component model should be consistent. That means
changing the structure of the binding component. At binding
operation and fault are different.
I will object to this unless we change the binding structure.
Roberto: Arthur said what I wanted to say. The proposal should be amended
to cover the binding.
Asir: I would like to understand what exact changes to binding are needed.
Arthur: As sanjiva showed in IRC, just as we have interface=QName in
binding, we also need fault=QName. In the binding for the
interface you need to be able to refer to the binding for the fault.
Asir: It is ok with me if you want to add this.
Marsh: So, the proposal needs to be amended before we can move forward
Sanjiva: I think so
Arthur: How about the suggestion Roberto made to define faults in
interface and reuse
Asir: We don't like it as we need to extend the interface to to it
Marsh: Is there an interest in developing an augmented proposal? Or
should we go for a straw-poll?
Sanjiva: The proposal as it stands is incomplete.
Arthur: Why is the idea to extend interface with faults not good enough?
Asir: I explained in my email
Marsh: It seems people are looking for amendment at the binding level
also to be able to support this proposal.
Sanjiva: I can not vote for this proposal without knowing how the other
(binding) part is going to work. This is a major change. We need
to see the full picture before we vote.
Sanjiva: Can we defer this until the F2F
Marsh: Sure. We will just postpone until then.
------------------------------------------------------------------
12. Issue LC20: Feature Composition Edge Cases [.1]
- Need Glen's input
- Also see LC27
[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC20
Marsh: Skipping. Need Glen's input.
------------------------------------------------------------------
13. Issue LC22: URI Style and SOAP Response Pattern [.1]
[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC22
Asir: Related to LC21. In light of resolution LC21, LC22 is no longer
an issue.
Marsh: Closed as rendered obsolete by resolution for LC21.
------------------------------------------------------------------
14. Issue LC23: Elaborate: Cannot be Serialized as XML 1.0 [.1]
[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC23
Marsh: The intent is to serialize as a different version of XML. Was
that the issue?
Asir: I understand it but, when some of our engineers found it puzzling until I explained issue 177
Marsh: It is our intent that you can serialize any valid set of
components as XML 1.1
Marsh: Can we reassign this as editorial to explain the above?
Asir: There is no relation to schema
Marsh: Or we can close it and say it is XML version issue only and
not related to schema
Marsh: Any issue to closing this with the above resolution
None. Closed.
------------------------------------------------------------------
15. Issue LC24: "ad:mustUnderstand" - ?? [.1]
[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC24
Asir: I don't see a use case for this or proper binding for the HTTP module
Marsh: We need to wait for Glen or DaveO
Skipped over
------------------------------------------------------------------
16. Issue LC25: What is a feature-binding? [.1]
[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC25
Asir: This is in the HTTP module that binds to the application data module.
They say it is a module and it is a feature-binding
Amy: That is because a module is how a feature is bound to SOAP
Marsh: Are you asking for a formal definition of feature-binding in the spec?
Asir: Yes. Also we are using both feature-binding and module term
Amy: That is because of different editors. If you can enter as editorial
Glen or I will clean up.
Marsh: Close LC25 with resolution, we will add a formal definition of
feature-binding in the spec; and we will check on consistent use of
feature-binding and module throughout the section
------------------------------------------------------------------
17. Issue LC26: wsdlLocation on the chopping block ? [.1]
[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC26
Asir: We do not have any concrete use cases for WSDLLocation. Saw one
for WS-MessageDelivery. It also says WSDLLocation may ref. WSDL
components as fragment identifiers. Do we have concrete use cases
for this also?
Anish: We do use WSDLLocation in our implementation to get to other WSDL
components. I will provide a detailed usecase via email.
NEW ACTION: Anish to provide a use case for WSDLLOcation via email
Roberto: Is there any new information in the LC issue to reconsider this
decision? Clearly majority of the WG thought it was useful. I do
not see any issue technical or otherwise for reconsideration.
Marsh: I am happy to go to vote directly. As to information, looking through
BPEL, Chor, Addressing and not actually finding any use case for
WSDLLocation. If they are not the ones the decision was based on
we may want to defeat this quickly.
Sanjiva: BPEL clearly depends on WSDL and BPEL cannot use it now because
WSDL 2.0 is not there yet. It will be used in the future when
they import WSDL stuff to refer to the location of the WSDL.
Roberto: WSDLLocation is meant to be used when you are passing service
element around as a reference.
Marsh: In WS-Addressing WG we are talking about providing reference to
the metadata you need to access the service in a reference. I can
imagine WSDLLocation being used in conjunction with WS-Addressing.
Asir: There is a 2nd part in the issue. Can we reference WSDL components
via WSDLLocation? It is in section 7.
Marsh: If we get rid of that part we need not answer the 2nd part.
Marsh: Lets take a straw-poll on whether we need WSDLLocation. Let us do
that.
Marsh: Question for poll: Should we remove WSDLLocation?
Straw-poll results: Yes - 1; No - 10 ; Abs - 1
Marsh: Asir, Ok with that?
Asir: Sure
Marsh: 2nd part. Should we allow fragment identifiers in WSDLLocation?
Marsh: Is WSDLLocation referring to a WSDL file? or a Definitions component
in WSDL?
Arthur: I don't think we should allow frag-ids in WSDLLocation. If you
want to refer to a WSDL component use frag URIs as described
in Appendix C. Namespace in combination with frag id.
Marsh: If I use WSDLLocation including frag-ids to something that is not a
Definitions component then it is an error.
Bijan: That is my understanding too.
Roberto: We should preclude use of frag-ids in WSDLLocation.
Marsh: The first sentence in section 7 is confusing. We should reword that.
Nothing wrong in using QNames to refer to WSDL components somewhere
else. WSDLLocation helps find the document that those WSDL
components are contained in.
Marsh: WSDLLocation identifies a Definitions component, not an arbitrary
component.
Bijan: Excluding frag-ids won't be sufficient. The regular URI may
dereference an arbitrary component. Not the Definitions component
only. That is what we want to preclude.
Prasad: Section 7.1 seems appropriate for that clarification.
Marsh: The first sentence in section 7.0 is confusing. It seems to imply
a URI can refer to an arbitrary WSDL component where as it is
actually talking about QNames as references.
Marsh: Proposed Resolution: Modify section 7 to remove any implication
that you can point to arbitrary WSDL component using WSDLLocation.
Marsh: I assume that is sufficiently precise resolution for the editors.
Marsh: Any objections to closing with the above resolution?
No objections. LC26 is close.
End of call
-
Received on Friday, 29 October 2004 21:35:09 UTC