See also: IRC log
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.
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
<scribe> postponed, don't have Arthur and Hugo today
waiting for addressing response
<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.
<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]
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
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
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
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)
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