Working Group home page · Meeting records
This is a draft version of the minutes.
See 25 April 2002 Telcon Agenda
April 18 minutes approved.
Philippe: latest version linked from the WG page
Jonathan: the latest version has added references
Philippe: patents - CPP says IPR disclosure is public, Process says it's not public, so we'll only publish the public ones, we'll try to get all IPR claims public
Jonathan: any showstoppers on the req. document?
None heard, we'll initiate the publishing of our first document.
Jonathan: two alternatives - we'll publish ASAP or after about three weeks because of a delay imposed by the W3C
Don Wright: I prefer not rushing it
Jonathan: is the early publication even viable from the standpoint of W3C?
Philippe: unless we do it today, we won't make it before the delay.
Jonathan: any objection on holding off the US document for the two to three weeks?
Jean-Jacques: we're using the old version of definition of a web service.
Philippe: the new version is:
A Web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols.
David Booth: I think we should track whatever the WS-Arch does
Jonathan: anybody not in favor of updating this definition? None.
Jonathan: we'll publish the req doc with this new definition, we'll hold off the usage scenarios doc
ACTION on US document editors to publish a version for review
Waqar: what do we do with the US document? Do we give it to the Arch group?
Jonathan: we'll work with the Arch WG to see which parts are common or theirs
Jonathan: we may need volunteers to match our Usage Scenarios with our requirements, possibly adding requirements from USs or removing unnecessary requirements.
Jonathan: do we have a resolution to this issue?
Keith: we need to make sure that the language is clear that the names are QNames
??: are there validation issues - does a processor have means to validate that the prefix is mapped to a real namespace name?
Jonathan: the type is QName so the validation is built-in
??: what is the difference between an NCName and QName?
QName is namespace-qualified, NCName cannot have a colon and does not belong inherently into any namespace
Jonathan: it took myself a long time to figure that a schema (and a WSDL document) is defining some names in the target namespace.
Jonathan: we cannot say that unprefixed QNames are namespaced in the targetNamespace because that would go against the definition of the type
Jonathan: we'll close the issue with the resolution that we'll improve the docs
Jonathan: I did get a reply from Satish that he thinks that there are better ways to solve the mirror-image problem than the solicit/response and notification operations. Hopefully we'll hear back from the WSFL authors more officially.
Jonathan: There's also the full-blown event mechanism that we may (but that most seem to be opposed to) introduce.
Jonathan: anyone to defend use of these operations for eventing?
Jonathan: Sanjiva had presented that these operations were being used for different things and weren't clearly defined.
Keith: people thought these operation would help with simple orchestration but it turned out to be false.
Glen: these more complex message patterns usually include other extensions which may mean that more messages than a simple request/response pair are transmitted for a logical request/response operation.
Jonathan: do we need a new design proposal or should we close the issue and then try to come up with the proposal?
Jonathan: we'll collect the usecases to identify precisely what problems these operations are trying to solve, Sanjiva et al. will come up with a proposal for changing the spec. The issue is left open.
Jonathan: we'll have to see where in WSDL 1.1 you can put extension elements or attributes. Many languages allow extension elements or attributes in virtually every place.
Jonathan: somewhere in between - attributes (from ##other namespace) anywhere, extension elements anywhere, but no behavioral changes result from this. So essentially the extensions are annotations. Attribute wsdl:required can identify required extensions that a processor MUST understand the extension because it may change behavior. Attributes wouldn't be markable with this, though.
Glen: the perceived assymetry between attributes and elements can be dealt with easily:
Jeffrey Schlimmer: in some cases the fairly closed content model is really restrictive even for annotations. Proposals for using the current extension points were ugly.
Jonathan: in XML Schemas, there are certain places which can have attributes, it has the annotation element in many places, too.
Jacek: do we have usage scenarios for extensions?
Glen: SOAP mustUnderstand extensions may need this
Jacek: in WSDL, describing mustUnderstand extension used in a service is an annotation, not an extension
Jeffrey: argument against extensions to WSDL - there is no need for it.
Jeffrey: we need mustUnderstand in WSDL so that WSDL can evolve
David Booth: say I'm defining a webservice and in so doing I'm defining types of the input. Clearly I cannot accept other types so these are required for clients of my service. This is different from extending the WSDL language itself.
We're tackling three problems here, we should discuss each one by itself.
Jonathan: we're at the end of our time, so let's try to break up the issue into its orthogonal parts:
Scribe: Jacek Kopecky