W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2004

Minutes, 8 April 2004 WS Description WG telcon

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 9 Apr 2004 13:19:46 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA203358ED2@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Web Services Description Working Grou;
2004-04-08 conference call minutes

Attendance:

Present:
 Erik Ackerman          Lexmark
 David Booth            W3C
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Youenn Fablet          Canon
 Yaron Goland           BEA Systems
 Hugo Haas              W3C
 Tom Jordahl            Macromedia
 Jacek Kopecky          Systinet
 Amelia Lewis           TIBCO
 Kevin Canyang Liu      SAP
 Jonathan Marsh         Chair (Microsoft)
 Josephine Micallef     Telcordia/SAIC 
 Dale Moberg            Cyclone Commerce
 Bijan Parsia           University of Maryland MIND Lab
 Igor Sedukhin          Computer Associates
 Jerry Thrasher         Lexmark
 William Vambenepe      Hewlett-Packard
 Asir Vedamuthu         webMethods
 Umit Yalcinalp         Oracle
 Prasad Yendluri        webMethods, Inc.

Regrets:
 Allen Brookes          Rogue Wave Software
 Ingo Melzer            DaimlerChrysler
 Jean-Jacques Moreau    Canon
 David Orchard          BEA Systems
 Arthur Ryman           IBM
 Sanjiva Weerawarana    IBM

--------------------------------------------------------------------
Agenda
1.  Assign scribe.  
2.  Approval of minutes.
3.  Review of Action items 
4.  Administrivia
5.  Task Force Status
6.  New Issues
7.  Effort to simplify our spec.
8.  Indicating HTTP version.
9.  Issue 165: Adding HTTPS support.
10. Issue 64: Operations as HTTP verbs
11. Issue 54: Allow binding to any HTTP method.
12. Issue 55: Define binding to HTTP headers.
13. Issue 147:HTTP binding uses static content-type-header
14. SOAP 1.2 Binding
--------------------------------------------------------------------
2.  Approval of minutes: April 1st telcon. Done
--------------------------------------------------------------------
3.  Review of Action items [.1].
PENDING   2003-09-18: Marsh to review the QA operational
                      guidelines.
PENDING   2004-01-08: Pauld to write up examples of schemas for the
                      Primer.
PENDING   2004-01-28: Philippe and JMarsh will look at the ipr for 
                      test suite.
PENDING   2004-02-12: DaveO to produce a refined proposal for Asynch 
                      HTTP binding addressing the concerns of folks 
                      that object to leaving replyTo info out of WSDL.
DONE [.7] 2004-03-05: DavidO to notify TAG about our decision on safety.
DONE [.2] 2004-03-11: JMarsh, David Booth, David Orchard to form adhoc 
                      group to explore stylistic rendering options.
PENDING   2004-03-25: Hugo to look at the Handling Privacy in WSDL 
                      2.0 for issues against our spec.
DONE [.3] 2004-03-25: Paul to review the XML Schema PER (by next week).
PENDING   2004-04-01: Marsh will get schema tf going.
DONE [.4] 2004-04-01: Youenn to create a specific proposal for
describing 
                      the HTTP version.
PENDING   2004-04-01: Editors to update SOAP 1.2 Strawman proposal to
                      take Part 1 changes into account.
DONE [.5] 2004-04-01: Youenn to provide editors specific text about 
                      https: uris
DONE [.6] 2004-04-01: Marsh to contact Mark Baker and see if @method 
                      satisfies him.

[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0006.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0000.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0012.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0011.html
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0002.html
[.7] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0014.html

---------------------------------------------------------------------
4.  Administrivia
  a. Upcoming FTFs
     - May 19, 9:00 AM - 5:30 PM
       May 20, 8:00 AM - 12:00 PM 
         (possible task force meetings in the afternoon)
       May 21, 8:00 AM - 4:00 PM
       Hosted by IBM in NYC
       Registration open
     - August 2-4 (London)
       Logistics, Registration to open shortly.
  b. Charter renewal - everyone needs to be reappointed
  c. Handling Privacy review
  d. Schema second edition review

    Discussion: a. Remember to register for May F2F meeting!!
                   August 2-4 F2F plans are near complete for London,
DBooth to open
                   registration later today.

                b. See action item below...

                d. PaulD: Schema second edition remains a difficult read
:)


    New Action Item: 1)Hugo: to ping Jon Marsh about people not
reappointed to to the working group.

                     2)JMarsh: to forward response about Schema second
edition to Schema working group.
------------------------------------------------------------------
5.  Task Force Status.
 a. Properties and Features (dormant)
 b. Patterns (dormant)
 c. Attributes (dormant)
 d. Media type description
 e. QA & Testing
  - Response to comments on QA Spec Guidelines [.2]
  - Implement QA Operational guidelines? [.3]
 f. Schema versioning
  - Waiting to hear back from Schema on my draft "charter."


		Discussion:

		Resolution: Pending

		New Action Item: None


[.1] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004Mar/0086.html
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0074.html
[.3] http://lists.w3.org/Archives/Member/w3c-ws-desc/2003Sep/0023.html

------------------------------------------------------------------
6.  New Issues.  Issues list [.1].

		Discussion: No new issues

		New Action Item: None

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html

------------------------------------------------------------------
7.  Effort to simplify our spec.
  - DavidB [.1] and Jonathan [.2] have provided some data points.

[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0162.html
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0006.html

		Discussion:

		JMarsh prefers to wait for David Orchard to be
		present before discussing too much further or deciding
on Editor's
		action items.....

		Bijan, suggest that maybe the intra-document linking
formatting
		proposed by JMarsh could be provided as a Non-Normative
alternative
		format.....

		Likely some simple stylistic changes (high-lighting
etc.) and the
		possibly re-ordering of some of the sections for better
flow.
		(standard boilerplate type information etc.)

		Need to review those parts considered "boilerplate" and
make sure
		there is nothing critical to the understanding of the
specification
		that might be misplaced if the boilerplate info is
re-arranged
		or collapsed.

		Resolution: Pending

		New Action Item: None

------------------------------------------------------------------
8.  Indicating HTTP version (related to Issue 164 [.1])
  - Youenn's proposal for describing the HTTP version [.2].

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x164
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0012.html

		Discussion:

		JMarsh reviewed Youenn's proposal briefly...
		Youenn.  HTTP version element used for either SOAP or
HTTP Binding.
		Jacek. Why Element and not Attribute?
		Youenn: Not opposed to changing to Attribute.
		Yaron: Use of Element allows for an extensibility point.
		Jacek: Need an example of required extensibility before
he's convinced.

<JacekK> yaron, could you show a simple example on how the HTTP version
is extensible?
<JacekK> yaron, maybe point me to the RFC
<yaron> JaceKK, ftp://ftp.rfc-editor.org/in-notes/rfc2145.txt
<JacekK> HTTP uses a "<major>.<minor>" version number
<JacekK> except for increasing the numbers, this is not extensible

		Discussed the features/properties extensibility
mechanism as alternative path......

		Umit: This info. may be valuable at run time so a
property may
		be appropriate.

		Yaron: There is utility to providing infomation in
addition to
		simply the HTTP version.
		States that there is usually/likely other information
about
		the HTTP server that would be of value and need to keep
this
		in mind when deciding the Element/Attribute/Property
issue.

		Glen/Umit: Co-oridiaton w/ XMLP? If there are properties
		of the transport required, we need use cases that
illuminate
		what these properties are first.......before deciding
the
		mechanism for HTTP version description.

		Jmarsh: General consensus detected that HTTP version
description is
		a good idea, however further discussion about what other
information
		may be needed/desired.

		Jmarsh: Are we ready to decide on syntax now??

		Jacek: Need to tackle issue of providing for
"additional" information or not
                first, and then address how....

		Jmarsh: Asked for objection to adopting Youenn's
proposal with Jacek's modification.
                    No objection....

		Resolution: Resolved(See Above)

		New Action Item:  3) Editors: to incorporate Youenn's
proposal [.2]
                                     with Jacek's modifications
(<http:support version="1.1"/>)

IRC Chatter:
<JacekK> Youenn's proposal is for <http:version value="..."/> - whenever
I see a 'value' attribute, the word "redundant" comes pops up in my mind
<Marsh> How about <http:version>1.1</http:version>
<JacekK> better, but still an attribute looks better here, I don't see
how http:version element could be extended in a meaningful way, even
with the experience of the different ways in which HTTP was extended
<JacekK> new stuff in, say, version 3.7, doesn't bring properties of the
version, but properties of HTTP
<yaron> I suspect people will want to add in information about
extensions they have into the version info
<JacekK> <http:support version="1.1" chunking="false" /> ?
* JacekK glen, are features extensible with unforeseen properties?
<JacekK> yaron, HTTP already has mechanisms for feature negotiation
within a single version
<alewis> compression, content negotiation, versioning, etc.
<JacekK> we discussed this last week
<JacekK> decided that we only needed the version number
<JacekK> not the various HTTP features
<yaron> The problem is that feature negotiations require additional
round trips which are expensive. Being able to express the info ahead of
time therefore is compelling.

<yaron> +1 to tossing coin

<yaron> +1 to JaceKK's proposal


------------------------------------------------------------------
9.  Issue 165: Adding HTTPS support [.1]
  - Youenn suggests specific text about https: uris [.2]
  - See also issue 56 [.3]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x165
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0011.html
[.3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x56

		Discussion:

		Issue x165:
		Youenn reviewed his proposal at:
	
http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0011.html

		Jmarsh: Are the words suggested by Youenn ready?.....Not
yet....

		Youenn: Might still be an issue at compile time/stubb
generation
		that ends up requiring support for both HTTP and HTTPS
because
		the requirement is not evident at this time...

		Yaron/Jacek discussed the actual (theoritical)function
of the bindings...
		Requirements of the binding's features vs. concrete
details of
		exactly how messages get transferred.

		Issue x56:
		Jacek: The specification of authentication mechanisms is
not necessarilly
		related to the privacy of the transport mechanism or
HTTPS/HTTP versioning
		issues.

		Jmarsh: Leave issue for now, hope to close next week ...
		Jacek: Suggest asking for the person raising the issue
for a suggested
		solution to x56 or further info on what he was asking
for.....

		Resolution: Pending

		New Action Item: 4)Jacek to write up his view of the
purpose of the bindings
				   to be discussed further before
deciding how to close issue x165.
<JacekK> what is it that the bpel people think bindings should do?
* JacekK will only be describing what he has always understood it to be

				 5)Jmarsh to contact the x56 commenter
for further info. regarding
				   this issue......desired
solutions/still an issue etc.??

------------------------------------------------------------------
10. Issue 64 [.1] Operations as HTTP verbs (Mark Baker) [.2, .3, .4]
  - Jacek's synthesis [.5].
  - Awaiting description from Philippe showing how properties or
    extensions can be used to annotate the WSDL with RESTful 
    properties.  Ask Mark for a definitive list of those properties 
    so we can consider how to associate them with property URIs or 
    namespaces.
  - Does the current draft [.6] with "method" attribute address this
    issue?  Not completely, Mark [.7] and DavidO [.8] reply.

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x64
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0103.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0111.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0094.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0095.html
[.6]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-bindings.
html#_http
[.7] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0002.html
[.8] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0004.html

		Discussion: 

		Jmarsh: Reviewed David Orchards email thread's, still
need
		more input from David to help drive this to resolution.
		Still not a clear understanding of the requirment space
to be
		able to design a solution for closing the issue.

		Hugo suggest that the web method feature of SOAP could
be used
		"outside the SOAP protocol" to describe the REST/Atom
requirments.

		Yaron/Hugo/JMarsh discussed the Rest/Atom
requirements/use models.

		Further discussion by group about the description of
arbitrary, application
		level operations and it's binding to HTTP operations....

				
		Resolution: Pending

		New Action Item: 6)Hugo: to propose "spec-ready" text
for hoisting the Web method
					feature of SOAP for use in a
non-SOAP binding.

------------------------------------------------------------------
Meeting Adjourned:
==================================================================
Un-Addressed items from the Agenda:
==================================================================
------------------------------------------------------------------
11. Issue 54: Allow binding to any HTTP method [.1]
  - Is this a subset of issue 64?

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x54

------------------------------------------------------------------
12. Issue 55: Define binding to HTTP headers [.1]
  - Do we want such capability?

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x55

------------------------------------------------------------------
13. Issue 147: HTTP binding uses static content-type header [.1]
  - "... we can today describe operations using messages 
    consisting in XHTML or SVG documents. Using the HTTP binding, 
    these messages will have the "application/xml" mime type 
    while it would be more appropriate to use more precise mime 
    types ("application/xhtml+xml" or "image/svg+xml" for
    instance). Therefore, it might be good to be able to set the 
    mime type to use for a given message, at least at the HTTP 
    binding level ..."

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x147

------------------------------------------------------------------
14.  SOAP 1.2 Binding
  - Review Jean-Jacques' schema [.1] outlining an overall approach to
    the binding.

[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0295.html
Received on Friday, 9 April 2004 16:20:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:30 GMT