- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 18 Jun 2004 17:00:10 -0700
- To: <www-ws-desc@w3.org>
Minutes, 17 June 2004 WS Description telcon
Present:
David Booth W3C
Allen Brookes Rogue Wave Software
Helen Chen Agfa-Gevaert N. V.
Roberto Chinnici Sun Microsystems
Ugo Corda SeeBeyond
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Youenn Fablet Canon
Tom Jordahl Macromedia
Jacek Kopecky DERI
Amelia Lewis TIBCO
Kevin Canyang Liu SAP
Peter Madziak Agfa-Gevaert N. V.
Jonathan Marsh Chair (Microsoft)
Mark Nottingham BEA Systems
David Orchard BEA Systems
Bijan Parsia University of Maryland MIND Lab
Jerry Thrasher Lexmark
William Vambenepe Hewlett-Packard
Asir Vedamuthu webMethods
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
Prasad Yendluri webMethods, Inc.
Regrets:
Hugo Haas W3C
Josephine Micallef Telcordia/SAIC
Jean-Jacques Moreau Canon
Arthur Ryman IBM
--------------------------------------------------------------------
Agenda
1. Assign scribe. Lucky minute taker for this week is one of:
Erik Ackerman, Adi Sakala, William Vambenepe,
Prasad Yendluri, Jean-Jacques Moreau, Umit Yalcinalp,
Igor Sedukhin, Dale Moberg, Paul Downey, Hugo Haas
William for first hour, Prasad after that
--------------------------------------------------------------------
2. Approval of minutes:
- June 10 [.1] (corrected)
[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0128.html
Approved as corrected.
--------------------------------------------------------------------
3. Review of Action items [.1].
PENIDNG 2004-04-01: Marsh will get schema tf going.
?ED 2004-04-29: Part 1 editors to adopt Jacek's "purpose of the
binding" text, without "interchangeable"
endpoints, and using "confidentiality" (or
similar) instead of TLS.
?ED 2004-05-19: Editors to include in the primer an example
that uses MTOM. (Issue 72)
?ED 2004-05-19: Editors to make propogation of modules and f&p
use the nearing enclosing scope. (Issue 180)
?ED 2004-05-19: Editors to fix component model to remove
default* properties, use mapping from syntax
instead. (Issue 182)
?ED 2004-05-20: Editors to incorporate Hugo's full potato
proposal. (Issue 54)
?ED 2004-05-20: David Orchard to update HTTP binding to
include discussion of how to generate an
accepts header from schema annotations
conformant to the media types extension
document, and to use outputSerialization
based on that information.
?ED 2004-05-20: Editors to incorporate http:{properties} into
binding.
?ED 2004-05-21: Sanjiva to implement the resolution that
@soapaction not there means no soapaction.
(Issue 1)
DONE [.3] 2004-05-21: Part 2 Editors to add such a statement.
(Issue 191)
?ED 2004-05-21: Part 3 Editors to add a statement to relate
each of the two soap meps to wsdl meps.
(Issue 191)
?ED 2004-05-21: Editors to add ednotes to the spec to
indicate areas that had contention. (Issue
190)
?ED 2004-05-21: Editors to remove @separator from HTTP
binding. (Issue 190)
PENIDNG 2004-05-21: DaveO to write up a scenario to motivate path
creation on a per-operation basis. (Issue
190)
DaveO would like people to comment on his example of HTTP binding usage
?ED 2004-05-21: Editors to write up that we allow
http:version etc. in the soap binding when
the protocol is http. (Issue 190)
?ED 2004-05-21: Editors to update part 3 to say that for SOAP
Response MEPs the URI will be generated
following the HTTP binding rules for
generating a URI (for GET). (Issue 61)
?ED 2004-05-21: Editors to update soap binding default rules
to allow use of MTOM. (Issue 184)
DONE [.2] 2004-05-21: Amy to provide wording to go into spec to say
that our bindings only support the identified
MEPs but others can be handled if appropriate
rules are defined elsewhere. (Issue 155)
?ED 2004-05-27: Editors to add http:faultSerialization
attribute.
PENDING 2004-05-27: DaveO will write up better description of
this issue (189).
PENDING 2004-06-10: Jacek to review XMLP specs.
?ED 2004-06-10: Editors should correct issues 208, 213,
215, come back to WG if there are any
questions.
[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0079.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0150.html
---------------------------------------------------------------------
4. Administrivia
a. - August 2-4 (London)
Logistics [.1], registration [.2].
- September 14-16 (Toronto) [.3]
- November (West Coast) volunteers needed
Volunteers to host nov F2F please make yourself known.
b. WSDL 2.0 Last Call game plan [.5]
- 2 hour telcons for next two weeks. Sorry about Canada Day...
DBooth: If we slip more than 3 months we need to go to the AC to
get reapproval.
DBooth and jmarsh: we can't slip.
[.1] http://www.w3.org/2002/ws/desc/4/04-08-f2f.htm
[.2] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004Mar/0064.html
[.3] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004May/0000.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0109.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0108.html
------------------------------------------------------------------
5. Task Force Status.
a. Media type description
- 1st Working Draft Published [.1]
b. MTOM/XOP
- Last Call Published [.2]
c. QA & Testing
- Suggested QA plan [.3]
- More details from Arthur [.4]
- Interop bake-off
d. Schema versioning
- Waiting to hear back from Schema on my draft "charter."
- Henry's validate-twice write-up [.5]
[.1] http://www.w3.org/TR/2004/WD-xml-media-types-20040608/
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0052.html
[.3]
http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/att-0029/QA_Oper
ational_Checklist.htm
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0037.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0019.html
------------------------------------------------------------------
6. New Issues. Issues list [.1].
- Cross-binding HTTP features (Asir) [.2]
Asir raised issue on cross-binding of HTTP features. Discussion of
whether this is editorial as daveO suggested.
Marsh will add this as an editorial issue, for tracking it's quick
dispatch.
- Mark N's comments [.3]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0080.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0138.html
------------------------------------------------------------------
7. Issues management [.1]. The following issues [.2] need a champion
to put forward a proposal:
158 ? Part 3 Design Setting HTTP headers in the HTTP binding
issue 158 - Setting HTTP headers in the HTTP binding
<pauld>
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0109.html
markN: i'll look into 158
change: glen and daveO to cover 158
168 ? Part 1 Design Which operation
issue 168 - dbooth to champion
dbooth: 168 as it stands can be closed quickly but there is a follow-up
issue
197 ? Part 1 Design Don't override interface feature
requiredness in binding
issue 197 - Don't override interface feature requiredness in binding
glen: i am interested in the issue but i need to re-read it
alewis: i was part of this discussion and i can champion it
jmarsh: alewis gets an AI to propose write-up language to resolve 197
ACTION: alewis to champion 197
210 ? Part 1 Design Refine equivalence algorithm
issue 210 - Refine equivalence algorithm
markN: i could come up with a proposal but i don't know what the
intent of the WG is
ACTION: markN to put together strawman for 210
211 ? Part 1 Design Omit interface message in binding?
issue 211 - Omit interface message in binding?
jmarsh: this sounds like an editorial issue
ACTION: markN to identify where clarification is needed for 211
218 Paul? Part 1 Design Justify interface faults.
issue 218 - Justify interface faults
ACTION: PaulD to propose text for part 1 to cover 218
[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0109.html
[.2] http://www.w3.org/2002/ws/desc/2/06/issues.html
------------------------------------------------------------------
8. XML 1.1 issues
- Issue 174: Tie WSDL conformance to XML conformance? [.1]
- Issue 175: Is it valid for a XML 1.1 document to import or
include a XML 1.0 document (and vice versa)? [.2]
- Issue 176: Can a WSDL 2.0 XML 1.1 document contain (or
reference), a XML Schema 1.0 type description? [.3]
- Issue 177: Normative dependence on XML Schema 1.0 precludes
XML 1.1 [.4]
- Proposed resolutions [.5]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x174
[.2] http://www.w3.org/2002/ws/desc/2/06/issues.html#x175
[.3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x176
[.4] http://www.w3.org/2002/ws/desc/2/06/issues.html#x177
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0049.html
issue 174 - jmarsh sent a proposal and got +1s
jmarsh: <summary of proposal>
dbooth: schema wg looked at it, there were people in favor and
some objections. in terms of schedule we can't depend on
their resolution.
dbooth: michael (from schema) did a write-up with several approaches,
one of which we could use as an alternative to defining our
own type
<dbooth> MSM's proposal:
http://lists.w3.org/Archives/Member/w3c-ws-cg/2004Jun/0005.html
[Plan B: forward motion only on XML
(B 1) Add the following note after the normative reference to XML 1.0:
At the time of publication, the version of XML named above was
current. All standards and technical specifications, however,
are
subject to revision, and conforming processors are allowed to
support more recent versions of XML in addition to the version
mentioned here.
In implementing this version of XML Schema, all conforming
processors[*] MUST support XML 1.0. They MAY also support XML
1.1
and/or other later versions of the XML specification. If a
conforming processor supports a later version of XML as well as
XML 1.0, then it SHOULD normally allow the user to control which
version is actually used; in particular, it is desirable that a
user be able to request that a document be required to conform to
XML 1.0, or to XML 1.1 or a later version, or to specify that any
version of XML is acceptable.
asir: why not wait for resolution in schema
jmarsh: we don't have much time...
jmarsh: we could do something for our last call but note that it is
subject to revision based on what happens in schema
asir: we can ask schema WG to solve this as fast as possible
jmarsh: would rather not have a dependency for our last call on this
jacek: to speed things up we could accept jmarsh's resolution and
say something like "this is not very important from process
point of view and this can change later in the process. we
chose to move forward without resolving this fully"
clarification - jacek meant any proposal really
jmarsh: i can write up a more detailed proposal to have our string
and name point to xml 1.1 rather than xml 1.0
dbooth: would this include datatype definition?
jmarsh: yes
ACTION: jmarsh to draft proposal to make wsdl strings refere to xml
1.1 and clarifying note
umit: i am afraid that we are requiring people to be xml 1.1
compliant while people use xml 1.0 processors
jmarsh: there is no dependency on parsing xml, we are based on the
infoset (in conformance section)
jamrsh: i don't believe my proposal requires an xml 1.1 compliant
processor
umit: ok, i'll make sure this is the case when you send your
proposal
asir: jmarsh will you define QName and other related types?
jmarsh: yes. the types that we used that changed are NCName, QName,
anyURI and token
issue 174, 175 and 176: jmarsh proposed to close them w/ no action
jmarsh: any objection to closing these 3?
(clarification) action 5 above (for jmarsh) relates to 177, not 174
<Marsh> RESOLUTION: Issues 174, 175, 176 closed
------------------------------------------------------------------
9. Issue 212: Explain using bindings across all operations [.1]
- Mark's proposal [.2]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x212
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0062.html
markN: (explaining issue 212) noticed there is no easy way to apply
same info to all operations in a binding
markN: the propoasl is that if there is no ref attribute the binding
info applies to all operations
tomj: i like the spirit but i am wondering what we have per
operation that we did not roll up to the binding
Glen: e.g. you might have operation specific binding features that
you can turn on and off
roberto: this proposal only covers operations. why not have a similar
mechanism for faults?
jmarsh: let's send this proposal back to mailing list to augment it
with faults support
dbooth: can we have a single consistent mechanism for doing this kind
of things
<Prasad scribes}
ACTION: Mark to make a proposal for issue 212 on the list
ACTION: Editor action to check that multiple style values are allowed.
------------------------------------------------------------------
10. Issue 216: RPC and XML Schema not orthogonal [.1]
- Mark's proposal [.2]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x216
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0064.html
Mark: provides a recap of the issue. Definition of the RPC style
implies that it can only be used on messages described by XML
Schema. That seems to be an unnecessary constraint. The
proposal is a modification of the language to allow any
language that results in the same structure can be used with
the RPC style.
Umit: Your proposal remove the MUST adhere to the constraints below
and made it "follow the rules". If that is the case I will
be objecting to the proposal. I would be happy to take it to
the list.
Mark: Sure.
Jonathan: If the wording is editorial, I would be happy to resolve
issue here.
Mark: Umit wants RFC 2119 level MUST added back
Jonathan: Any objection to closing the issue with the normative MUST
adhere to the constraints added (back), as a friendly
amendment?
<none>
Jonathan: Consensus to close issue 216 accepting Mark's proposal with
a normative MUST added.
RESOLUTION: Issue 216 closed.
ACTION: Editors to adopt Mark's proposal for 216, but reword using
MUST.
------------------------------------------------------------------
11. Issue 217: Syntax for multiple styles [.1]
- Mark's plea at [.2]
- No new information presented, issue will be closed by chair.
Allow for minority objection write-ups if necessary.
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x217
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0059.html
Jonathan: Asked for new info why an attribute based extensibility is
better? We have gone through this before (issue 98).
I propose we Close this issue with no action. We don't have
any new information.
Mark: No negative comments on the issue on the list.
Jonathan: There was support for this proposal before but, majority
felt they prefer the style attribute in WSDL namespace.
That was the consensus we reached.
Mark: Ok
Jonathan: Issue 217 closed.
Jonathan: Checks with Sanjiva if this got reflected in the spec.
ACTION: Editor action to check that multiple style values are allowed.
------------------------------------------------------------------
12. Issue 221: Identify components by URI [.1]
- Jonathan's proposes closing with no action.
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x221
Mark: I am willing to withdraw the issue
Jonathan: I am also proposing we close with no action
Jonathan: Quick summary of the issue. Why are components identified by
a QName instead of a URI.
TomJ: Are you talking of Operation, Port, Interface that kinda
stuff?
Jonathan: Yes, each component has an NCName and a namespace associated
with it. When you refer to them from other components, you use
the QName. Changing all QName refs to URI refs that is implied
by this proposal is a major change at this point.
TomJ: Also impacts the usability in a negative way.
Jonathan: Any last comments before this issue gets closed?
DaveO: We also do have the fact that these components can be
identified
by URIs.
Jonathan: Yes, we provide a mapping.
Sanjiva: We provide that mechanism.
Jonathan: We don't use the mechanism internally but someone else can.
RESOLUTION: Issue 221 is closed.
------------------------------------------------------------------
13. Issue 222: Name[space] for the intended semantics [.1]
- Mark's proposal is in the issues list [.1]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x222
Mark: Proposal change in section 2.1.1: "an unambiguous name for
the intended semantics of the components." -> "an unambiguous
name *space* for the ..."
DBooth: I wrote that sentence. I did mean *name* rather than
namespace.
The intent is that, the targetNamespace URI acts as an
unambiguous name for intended semantics of the components as
a whole, rather than individual things.
Mark: If added 'as a whole' I would have understood it.
DBooth: O.k. Lets add that or collection of components
Jonathan: So resolutions to change it from "an unambiguous name for
the intended semantics of the components." to "an unambiguous
name for the intended semantics of the *collection of *
components."?
DBooth: Yes.
Jonathan: Editorial. Any objections?
<none>
RESOLUTION: Issue 222 resolved as above
ACTION: Editors to incorporate editorial fix addressing issue 222.
------------------------------------------------------------------
14. Component model issues
- Issue 223: Import/include processing model [.1]
- Issue 224: Formalize component model [.2]
- Mark's proposal [.3, .4]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x223
[.2] http://www.w3.org/2002/ws/desc/2/06/issues.html#x224
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0085.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0094.html
Jonathan: Considering these together as the proposals came together.
Mark: This is just an expansion of the introductory text to section
2
to talk about what the component model is and how it is
structured. Also add a small note regarding the notation of
the {} syntax. It would be nice to talk about how new
properties can be introduced to the spec.
Jonathan: Basically changes that improve the readability of the spec
rather than any features of the WSDL language.
Mark: There is no guidance on how the properties can be namespaced
for extensibility.
Jonathan: The infoset does not namespace properties. Those names are
namespaced to the specification
Mark: If we add stuff to Infoset, we can not call the resulting
structure an Infoset. We have to call it something else.
Jonathan: For instance XInclude adds a language property to the infoset
Mark: May be this is a separate issue for XML Core then
Jonathan: Is it not sufficient to identify a property uniquely, by the
name of the property and the spec that defines the property?
The names of the properties don't appear in the syntax. They
are referred to by other specifications. Kind of like a
QName reference. Is it not sufficient?
Mark: It is a good specification to be precise about it.
Jonathan: So, what should the other specifications do?
Mark: I can come up with a proposal for consideration separately
ACTION: Mark come up with a proposal for extension property namespacing.
Roberto: Schema itself does not do this for the PSVI. Also for the
schema components it does not introduce namespaces for the
property names.
Jonathan: Going back to the original issues. Any objections to accepting
Mark's proposals for 223 and 224
Roberto: In the proposed text do you mean components are "collections
of named properties" rather than "named collection of
properties"?
Mark: Components have names
Roberto: You mean named as in the kind of the component
Mark: Would you prefer "type' there?
Roberto: Yeah, it can be editorial though
Jonathan: Lets get this in the resolution so that editors have it. So,
friendly amendment to use "typed components" rather than
"named
components". Any other comments?
<none>
Jonathan: Consensus to close 223 and 224 with editorial change proposed.
ACTION: Editors to incorporate proposed resolution for 223 and 224.
------------------------------------------------------------------
15. Issue 207: How to mark which elements to optimize [.1]
- See thread starting at [.2]
- Jonathan's proposal based on last week's straw polls [.3]
- Related issue on F&P? [.4]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x207
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0020.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0139.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0042.html
Jonathan: Proposal at:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0139.html.
Proposal was to ask to XMLP WG to add text to the description
in MTOM that talks of how to choose things to be optimized.
Essentially to have the word MAY in there and a reference to
expected media-types schema annotation. Say something like,
implementations may rely on information in a description such
as presence of a value xmlmime:expectedMediaType schema
annotation and reference to the specification.
Jonathan: Umit, are you ok with this proposal?
Umit: Yes, the more declarative power we give the better
Jonathan: You prefer a SHOULD than a MAY or a MUST?
Umit: Even if we do have a MUST, we have to describe how to do it.
Somebody has to provide details on how to utilize that
information. If XMLP is going to do further work on MTOM that
is better but, I am not sure.
Umit: If there is are options to serialize oneway or other, some
kind kind of capability to specify that I am expecting to
serialize this kind of mediatypes as attachments all the time.
Jonathan: Question is, whether that policy needs to be in WSDL
Umit: As a feature or extension properties that specify expecting
to serialize this kind of mediatypes as attachments all the
time.
Jacek: From XOP/MTOM point of view a SOAP node does not know that
something was serialized as an attachment. Before the SOAP
node processes a message, all attachments are virtually in the
envelope. So, wondering if we can allow parties requiring
stuff
to be in attachments? From SOAP POV this is not wanted. So I
agree this is really an optimization and once we start using
MUST it stops being that.
Jonathan: Lets see if we can go back and see if my proposal is
acceptable enough for us to move on here.
DBooth: If I understood Umit's concern, it can be accomplished with
properties of a feature outside of the WSDL.
Jonathan: XMLP WG would be a better place for defining that feature or
properties.
Umit: That was the question I had. If the XMLP WG is going to
take something like on?
Mark: Probably not.
Umit: Somebody is going to solve this problem oneway or other.
The problem is not going to go away. My concern is who is
going
to resolve it.
Jonathan: Can we try and move the agenda fwd. Are there objections to
asking XMLP WG to handle this? I proposed some words and a
place in the spec where they might do that.
<no objections>
Jonathan: Proposal is accepted and Issue 207 is closed.
ACTION: Marsh to forward Issue 207 proposal to XMLP WG.
Jonathan: A Q about what required means on MTOM feature. If we need to
put something in our spec to make it clear.
DBooth: I wrote up an explanation on this. Some text could be put in
the processor conformance section. Section 8.3 ....
Jonathan: Is this non-controversial or need to raise a separate issue?
DBooth: Only Ugo had a push back:
Ugo: The push back was on which pov is the interface described
from client or service.
Jonathan: We discussed this extensively in the past.
Ugo: I don't want to revisit the decision
Jonathan: Ack'ing we can't do anything about that, is the proposed
change acceptable to all?
<no objections>
ACTION: Editors to incorporate David Booth's clarification in section
8.3
This is also closed.
Reached end of proposed Agenda. Anything else?
Meeting Adjourned.
----------------------------------------------------------------
Summary of New Action Items:
ACTION: alewis to champion 197
ACTION: markN to put together strawman for 210
ACTION: markN to identify where clarification is needed for 211
ACTION: PaulD to propose text for part 1 to cover 218
ACTION: jmarsh to draft proposal to make wsdl strings refere to xml
1.1 and clarifying note
ACTION: Editor action to check that multiple style values are allowed.
ACTION: Mark to make a proposal for issue 212 on the list
ACTION: Editors to adopt Mark's proposal for 216, but reword using MUST.
ACTION: Editors to incorporate editorial fix addressing issue 222.
ACTION: Mark come up with a proposal for extension property namespacing.
ACTION: Editors to incorporate proposed resolution for 223 and 224.
ACTION: Marsh to forward Issue 207 proposal to XMLP WG.
ACTION: Editors to incorporate David Booth's clarification in section
8.3
Received on Friday, 18 June 2004 20:01:08 UTC