W3C

WS Description WG telcon

8 Sep 2005

See also: IRC log

Attendees

Present:
Charlton Baretto, Adobe Systems
Rebecca Bergersen, IONA Technologies
Allen Brookes, Rogue Wave Software
Roberto Chinnici, Sun Microsystems
Glen Daniels, Sonic Software
Paul Downey, British Telecommunications
Youenn Fablet, Canon
Tom Jordahl, Macromedia
Anish Karmarkar, Oracle
Jacek Kopecky, DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria
Kevin Canyang Liu, SAP
Jean-Jacques Moreau, Canon
David Orchard, BEA Systems
Bijan Parsia, University of Maryland MIND Lab
Tony Rogers, Computer Associates
Asir Vedamuthu, Microsoft
Umit Yalcinalp, SAP
Regrets
Arthur Ryman, IBM
Observers
Carinne Bournez (W3C, substituting for Hugo)
Chair
Jonathan
Scribe
JacekK

Contents


minutes from last week approved

Review of Action items [.1].

PENDING   2005-06-16: Amy to provide test cases for MEPs not described
                      in Part 2, due 2005-07. 
PENDING   2005-07-20: dorchard to respond to commenter on keeping 
                      mustUnderstand 
PENDING   2005-07-21: pauld to write a proposal for a working group 
                      report for requirements for schema evolution 
                      following closure of LC124 
PENDING   2005-09-01: Marsh to propose some text to address LC305 in 
                      terms suitable for both WS-A and WS-D, 
                      due 2005-09-08. 
DONE [.3] 2005-09-01: Marsh to mark LC319 as non-editorial and ask for 
                      a proposal from Hugo, due 2005-09-08. 
DONE [.4] 2005-09-01: Jonathan to run LC301 past WS-Addressing to get 
                      confirmation, due 2005-09-08. 
DONE      2005-09-01: Marsh to include "Z notation in Part 2" in next 
                      agenda, due 2005-09-08.

Administrivia

welcome to Charlton as rep for Adobe

upcoming f2f dates: one in less than 3 weeks; logicstics not yet there

Tomj: the registration is closed?

Marsh: if you missed it, please email me and we'll see what we can do

<Tomj> http://www.w3.org/2002/09/wbs/34041/wsdwgf2f0509/

Carine will reopen the registration for a few more days

Z-notation in part 2

<scribe> postponed, don't have Arthur and Hugo today

LC301

waiting for addressing response

LC303

<scribe> ACTION: Kevin Liu to propose text for talking about IRIs in primer (from Hugo's suggestion) (after next week) [recorded in http://www.w3.org/2005/09/08-ws-desc-minutes.html#action01]

<Tomj> I would like to see URIs used in the text (especially the primer) with just a mention that WSDL supports IRIs, which are a superset.

LC305

LC315

<Tomj> Introducing a "new" TLA is not very friendly as people are just figuring out what a URI is...

<TonyR> Well, so many of them have more than 3 letters, so we have things like 4 letter acronyms, called Four Letter Acronym Packages, or FLAPs

Tomj: suggest we trust Hugo

Marsh: we need to review the proposal nevertheless

uyalcina: we seem to lack use cases

Tomj: it seems useful to add HTTP headers
... and restricting this to use only a few XML Schema types is reasonable

Marsh: do we want to talk about integers, for example?

Tomj: not necessary
... I move we accept the proposal

<RebeccaB> It's Jonathan's line that's making the noise. It went away when he was muted.

Tomj: a year ago we wanted to keep it simple, just string, then somebody suggested URI to be added

<GlenD> so fine, just say "not complex content"

Roberto: there's a simple type that's not just a string - QName

Marsh: so for simplicity we want to restrict it
... so why URI? it's a string, after all

uyalcina: do we accept xs:int, then?

Marsh: only derived types from string and anyURI

Roberto: is union derived type?

asir: nope

Marsh: if we want it simple, we don't need derived types, or we should allow ints and the rest

Tomj: I suggest we reject point 2, unless Hugo argues strongly for the derived types

Roberto: union and list seem to be "derived" as well in XML Schema

asir: "constructed"

Roberto: sec 2.5.2 in XML Schema part 2 says derived
... maybe "derived by restriction" would be useful

asir: could be good

Roberto: allowing enumerations could be useful, that's a restriction derivation

Marsh: instead of "derived types" you would say "enumerated types"?

Roberto: "derived by restriction"

Marsh: if derivation, why not int?
... it's going to be serialized as characters in the HTTP header, this typing is useful for validation
... so maybe everything but QName

JacekK: I don't think leaving QName out helps much

Marsh: either we should allow int (and derivations by restriction), or why should we restrict this at all?
... we might note QNames could be hairy

JacekK: or we may keep silent

dorchard: IIRC the reason for string and anyURI is "the simplest set of types we can easily agree on"
... I don't recall a reason against int

Marsh: yup, seems arbitrary

dorchard: the Depth header is already defined basically as int

Marsh: we go from XML element to HTTP header
... why force people to lie about the type (string for int)
... what does it simplify?

JacekK: if we go from XML element, we have characters, we don't need to constrain the type for serialization simplification

Marsh: proposal: the type of the element must be a simple type

JacekK: and simple content?

Marsh: simple content is probably sufficient

asir: simple content can be used with attributes in complex type

Marsh: so we'll ignore attributes, we say the element has to have simple content
... we have to run this by hugo
... can we adopt the first part of Hugo's proposal?

resolved: adopted

<scribe> ACTION: Marsh to write up the proposal (simple content, no type restriction) [recorded in http://www.w3.org/2005/09/08-ws-desc-minutes.html#action02]

LC317

Marsh: reads the issue

Tomj: what is the IRI style?

Marsh: like RPC style but only simple types

JacekK: so it can be serialized as query parameters in URI
... the use case is a hypothetical binding that has out-in mapped to http request/response going from the service

Tomj: and the cient has to have HTTP server?
... so the first message has to be serializable in URL
... it makes the text less understandable
... no problem with Hugo's text

Marsh: resolution: issue closed, proposal accepted

LC318

asir: the default binding rules is more like an extension to binding; then specifying the default value happens on the markup level

JacekK: I was mildly confused, but it was not a problem

Marsh: doesn't seem we want to adopt it
... may postpone for Hugo

LC319

LC320

JacekK: would it be a simple single reference that every component has {parent}?

<dorchard> doesn't the infoset have this? :-)

Marsh: nope, we have to list it everywhere
... resolution: issue closed, proposal accepted

LC321

asir: related to LC98
... we had this statement and moved it to default binding rules

<asir> http://www.w3.org/2002/ws/desc/4/lc-issues/#LC98

asir: the removal was implemented, the move was not implemented

Marsh: so if we add it to the default binding rules (5.11.3), that would solve this?

asir: that's what we decided in LC98

JacekK: do the other bullets contain similar text in similar situations?

asir: the second bullet in 5.11.3 should say absence of the value is an error

Marsh: two proposals: add the error text in 5.11.3 or in table 5-4

JacekK: the error text should be in 5-4 because the default rules may not be applicable

Marsh: so can we add it in table 5-4?

asir: what happens in the case of SOAP 1.1?

JacekK: maybe we need to make {soap mep} optional in 5.8.2

asir: I thought that was handled in LC98
... doesn't seem it got implemented

Marsh: can we regroup and get a fresh proposal?

<scribe> ACTION: asir to put such a proposal together [recorded in http://www.w3.org/2005/09/08-ws-desc-minutes.html#action03]

ACTION 3=asir to put such a proposal together (making {soap mep} optional property, specify the error for SOAP 1.2 default bindings)

ACTION 3=asir to put such a proposal together (making {soap mep} optional property, specify the error for SOAP 1.2 default binding rules)

LC323

JacekK: {http output serializaton} is required, maybe it needs to be optional or have an #any token

Marsh: if we know the media type, we can put it in the Accept header

asir: so the issue is a clash between output serialization and expected media type

JacekK: we might just drop the Accept headers bullet from 6.3

asir: it would not make the clash go away

JacekK: so expectedMediaType is a list of media types?

Marsh: yes

TonyR: can we have test for this MUST?

Marsh: yes
... that would the the "expectedMediaType MUST be consistent with {http output serialization}"

dorchard: if we go there, we should say they have to be equal

uyalcina: MTXML is a note, if used together with WSDL, it's kinda undefined
... so we may not be able to put a MUST about this thing

Marsh: expectedMediaType is not in the infoset anyhow

JacekK: if we drop the bullet on Accept headers (which we can because the Accept headers are not useful here as we know exactly what comes back), we drop the only reference to expectedMediaType

dorchard: we don't do content negotiation

uyalcina: it says Accept MAY take into account expectedMediaType

dorchard: what if two operations on one URI had different content type returned?

Marsh: so "the client may put the {http output serialization} into the Accept header"?

JacekK: it would be a way, in old terms, of fulfilling the operation name mapping requirement

Marsh: but the client should know to do it
... we're out of time, current proposal is to drop Accept bullet

dorchard: I'll try to describe the scenario

Marsh: maybe it's a different bullet
... call adjourned

what is it with the squared circles anyway? 8-)

<charlton> :-)

<caribou> a bread-to-jam binding?

<caribou> jam types?

<caribou> oh, what's the optional binding then?

<caribou> lol @ the w3c and ws-desc tags

<caribou> bye happy WSDL'ers

Summary of Action Items

[NEW] ACTION: asir to put such a proposal together [recorded in http://www.w3.org/2005/09/08-ws-desc-minutes.html#action03]
[NEW] ACTION: Kevin Liu to propose text for talking about IRIs in primer (from Hugo's suggestion) (after next week) [recorded in http://www.w3.org/2005/09/08-ws-desc-minutes.html#action01]
[NEW] ACTION: Marsh to write up the proposal (simple content, no type restriction) [recorded in http://www.w3.org/2005/09/08-ws-desc-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2005/09/08 16:49:52 $