WS Description WG 19 May 2005 telcon

19 May 2005

See also: IRC log


Rebecca Bergersen, IONA Technologies
Allen Brookes, Rogue Wave Software
Roberto Chinnici, Sun Microsystems
Kendall Clark, University of Maryland MIND Lab
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
Amelia Lewis, TIBCO
Kevin Canyang Liu, SAP
Dale Moberg, Cyclone Commerce
Jean-Jacques Moreau, Canon
David Orchard, BEA Systems
Tony Rogers, Computer Associates
Arthur Ryman, IBM
Adi Sakala, IONA Technologies
Sanjiva Weerawarana, Invited Expert
Umit Yalcinalp, SAP
Hugo Haas, W3C




<Marsh> Updated agenda available: http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0065.html

<scribe> scribe: jacek


minutes accepted

action items

?*        2004-11-11: Anish to propose additions to the test suite for 
                      the purpose of interoperability testing, 
                      due 2005-05-12.
?         2005-03-31: Marsh to take on (or recommend closing) Bijan's AI
                      to produce a component/property table via XSLT, 
                      due 2005-05-28.
?         2005-04-21: Pauld to craft, publish Common Schema structures
                      to WG for review for publication as WG Note, 
                      due 2005-05-28. 
?         2005-04-21: Hugo to continue to look at IRI style/URI style,
                      due 2005-05-26. (LC74a)
DONE [.7] 2005-04-22: Umit to write an alternate proposal, 
                      due 2005-05-19 (LC117)
?*        2005-04-22: Amy to provide examples for the advanced section 
                      of the primer. Amy to send them to Kevin and test 
                      materials to Arthur, due 2005-05-19. (LC61c) 
DONE [.5] 2005-04-22: Arthur to investigate the Schema Designators and 
                      come back with a proposal, due 2005-05-19. (LC64) 
?*        2005-04-22: Amy to investigate a solution, due 2005-05-19
DONE [.8] 2005-05-05: Umit to writeup a simple proposal to make {safety}
                      as an extension, due 2005-05-19. 
DUE 5-26  2005-05-05: Sanjiva to writeup a proposal for LC71, 
                      due 2005-05-19.
DUE 5-26  2005-05-12: Glen to add scoping example to primer, due ?. 
DONE [.3] 2005-05-12: Marsh to ask charlton to send his comments to WSA
                      except the wsdl11/20 terminology comment, due 
DONE [.4] 2005-05-12: Marsh to add MEP template as LC128, due 

Outstanding editorial work:
DONE [.6] 2005-04-21: Hugo to define frag id extensions for 
                      soap:header, http:header, soap:module. (LC80)
?         2005-04-28: Arthur to introduce specialized markup for 
                      components and properties.
DONE      2005-05-12: JJM to incorporate Glen's LC18 suggestion. 
?         2005-05-12: Primer editors to remove section 7.1.2 - we don't
                      define scoping rules for extension elements.

[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://www.w3.org/2002/ws/desc/4/lc-issues/actions.html
[.4] http://www.w3.org/2002/ws/desc/4/lc-issues/issue.html#LC128
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0041.html
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0035.html
[.7] http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0062.html
[.8] http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0059.html

discussion of MathML version of the spec (for Z notation)


Marsh: bijan has cancelled his attendance, otherwise we're final
... put up a revised agenda

<pauld> what's the story on net access?

Marsh: added Arthur's Z notation MathML version here

Arthur: looked into MathML because it's less objectionable than the current version requiring font substitution in IE
... a MathML version requires XHTML, displays natively in Mozilla but IE needs a plugin
... still the stylesheet does browser sniffing which was originally a problem for Hugo

Marsh: we'll have to wait for Hugo with this

incoming LC issues

Marsh: umit's issue referred to the editors (with no objections)
... that's the issue about wsdli:wsdlLocation
... issue about what the purpose of #none is
... unclear about what needs to be fixed

uyalcina: there is no guidance on how/when to use #none
... we need more illustrative example for the use of #none (or any other # things here)

Tomj: I agree

kevinl: we might add a special example

uyalcina: I can propose an example if we agree that's useful
... instead of having big example it's good to have smaller examples even if the features get reused later

Marsh: anybody objects?

Tomj: it's always good to put more examples to the primer

Marsh: that's our plan then
... giving Umit an action item

<Marsh> ACTION: Umit to provide #none for Primer due: June [recorded in http://www.w3.org/2005/05/19-ws-desc-minutes.html#action01]

Marsh: another email about making description/@name mandatory, let's not add it as an issue

sanjiva: we removed the attribute, right?

Tomj: I liked the attribute, it did no harm and could actually do some good

sanjiva: in 2005/5/10 WD we have no name attribute

Arthur: this will cause a problem for the component model
... adding the attribute, that is
... because we'd have to have multiple description components all of a sudden
... still waiting for replies from the commentor

sanjiva: the commentor refers to WSDL 1.1

Marsh: let's not add this as an issue at this moment
... I'll point out to the commenter that we're soon in new LC, he can re-comment

editorial issues

Marsh: lc121, lc127 finished by editors, any objections to closing them?
... nope, issues closed

RESOLUTION: LC 121, 127 closed.

issue lc64

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0041.html

Arthur: since element decls and type defs are components, we should have URI references for them; maybe we can use schema component designators
... it's not rooted in this situation, the SCD refers to elements within schema, not to qnames
... we aren't tied to schema
... the proposal is in line with the current syntax for the other components
... two more pointer parts (with two arguments each), including URI identifying the type system, assuming other type systems also have URIs
... we can prefer XML Schema with a shorthand for that
... then there's the description component, I'm proposing a description() pointer

uyalcina: for the element decls, we'd have both the shorthand and non-shorthand version available together?

Arthur: yes, we'd need both

Marsh: what is the difference between using SCDs and the proposed approach?

Arthur: the fragment syntax is tied to the media type, ours (wsdl) doesn't include SCDs as fragments, we'd have to extend ours to include that and still we'd have to invent the other stuff for the other type systems
... non-XML type systems are just extensions, can use our extension fragment syntax for that

uyalcina: I like this approach because SCDs are not widely supported and ours is simpler

Marsh: I thought the whole reason for this was to have a canonical way for URIs for components
... now schema has other canonical URIs for the same thing, no longer being canonical then

Arthur: we have a different thing than what schema has, different components
... our component model doesn't contain schema components, we have invented element declaration and type definition, more general than schema's

Marsh: and this doesn't link to the schema component

Arthur: we only care about the qname, really

Marsh: so the qname is the link, no URIs

Arthur: the short form for XML Schema gives us two ways so we'd not have canonical; we could try to handle this with explicit canonical rule

Marsh: do we have problems with commas in the syntax?

sanjiva: we don't have type definitions any more, do we?

Arthur: property components use them, they were brought back

a bit of discussion on interplay of different schema languages and the type definitions

all is OK

JacekK: could we drop the long way for XML Schema? we wouldn't have problems with canonicalization

Arthur: we could drop it but wouldn't help char-for-char canonicalization

Marsh: amendment: the URI is optional, omited for XML Schema, included for others, can the optional parameter be second?

Arthur: I'm fine with that

Marsh: must make sure that when we talk to XML Schema WG we can tell them we cannot use SCDs because we don't share their components

<uyalcina> +1

Marsh: so two amendments: URI parameter second, not there for XML schema
... any questions on description()?

Arthur: for completeness

JacekK: we don't need to refer to this particular component

Arthur: goes back to discussion whether we need this top-level component
... for consistency I'd like to have a fragment for it
... or drop the top-level component

JacekK: we need a URI for the component, not a fragment

uyalcina: same, we could reuse the target namespace for this

Marsh: is there any harm with having this fragment for this component?

alewis: is this a pointer to the whole thing (component model) or just the single component?
... any issues about includes etc?

Arthur: at this level we don't have includes etc.
... and the pointer goes to the component

Marsh: any objections to accepting Arthur's proposal with the two amendments?
... nope, issue lc64 closed

RESOLUTION: LC64 closed.

issue lc90

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0042.html

Arthur: Paul wants to use different definitions for the same element on different message references (and potentially faults)
... his proposal is to have multiple types sections
... his proposal is not consistent with the meaning of schemaLocation
... but for inlined schemas it could work
... the SCD spec can point to a specific file
... so my counterproposal would be to have an extension that would use SCD for the definitive location of the definition
... the upshot is that using WSDL's extensibility one could do it, little impact on our spec

Marsh: so this attribute would allow you to find a particular version of a schema, how would it help?
... oh, it would be on the input element

Arthur: or wherever you have an element="..." attribute for this functionality

Marsh: SCD is not on namespace?

Arthur: one can have an absolute pointer to a particular schema document

uyalcina: I'm fine with Arthur's proposal, would Paul ask us to bles this particular extension?
... I'd be uncomfortable with that

Arthur: we could still handle it as an extension, though

JacekK: would there be any impact on our spec?

Arthur: this is an existence proof that the solution exists
... we could put it in part 2 if he makes a strong case for it

<sanjiva> I'd be -1 for putting this extension into our wsdlx namespace; I don't see it as a widely used feature at all.

Marsh: would the extension survive our CR process?

<sanjiva> Its not going to be implemented in the Apache stuff for sure :)

uyalcina: probably not

Marsh: we could say: we have existence proof but little confidence that it would be implemented
... any implementors would tackle this?

silence and one no

Marsh: close the issue with no action, communicate the results of the discussion back? Any objections?
... LC90 closed as just outlined

RESOLUTION: LC90 closed.


Marsh: this issue has already been closed, but we had some more traffic coming from the resolution
... on component designators for our binding extensions
... proposal to provide designators for the extensions using our already existing syntax
... do we want to wait on this? It's already closed...
... seems like an editorial detail on Hugo's part, will continue to track this

LC75c - remove the safety property

uyalcina: proposal to move the property to an extension
... removed from core, moved to an extension, we need a namespace for "well defined extensions", created one, put there the boolean attribute, in part 2

dorchard: I'm against the proposal, concerned about companies not implementing the predefined extensions, it slips through the cracks and people effectively don't get this functionality; I think it's important in the core of the spec
... I proposed a different solution, we never did that
... safety is one of the most important tenets of the web architecture; therefore it should not be moved

<Arthur> +1

JacekK: is the invented URI for "well defined extensions" special for safety or more general?

uyalcina: we need a namespace to group the extensions we define
... my other proposals reuse the namespace

Marsh: we need not talk about this, we have one namespace on the table now

JacekK: please note this if the namespace gets reused later by other proposals

pauld: echoing a lot what daveo already said
... it's important for us that safety is core to WSDL
... safety is one of the key properties, simplifications of WSDL keep that, few other things
... so the social expectations about this would make it much less available if it was an extension

Marsh: the original comment was about the tooling not being able to guess safety, thus leaving it false

pauld: but .net can add safety as code annotation

<Zakim> alewis, you wanted to ask about semantics

pauld: would have people thinking about this

<kendall> +1 to alewis's point

alewis: I didn't think safety meant cacheability, for example getCurrentTime is safe but not cacheable
... so using safety you are not establishing cacheability

Arthur: my understanding of safety is "you can use get"
... the spec says it more generally

<pauld> just enabling using GET as opposed to always having to use POST would be of great value

Arthur: what we really need is a way to say "you can use get", because that's usually cacheable, 99% ops are retrieval ops
... agree with pauld that if tooling is the problem with the safety property, it's not much of a burden to add the annotation to the code

dorchard: the tooling argument has two ways of looking at it: platforms have various annotations and safety annotation is easy to do
... saying it doesn't exist doesn't hold that much water with me

<Marsh> Safety "defined": http://www.w3.org/TR/2003/WD-webarch-20031209/#safe-interaction

dorchard: but if we're generating the interface from class descriptions, we don't have that annotation
... but with the "WSDL-first" style safety can be put there and would be important
... agree with Arthur that "gettability" is well above the 80/20 threshold; I'd be interested in trying to achieve this kind of functionality

<Arthur> see: HTTP GET is safe; i.e., agents do not incur obligations by following links.

<Arthur> http://www.w3.org/2001/tag/doc/whenToUseGet.html

<dorchard> jacekK, I agree Put can be idempotent. But the 99/20 point for the Web & Web services is GET/POST...

<pauld> the results of not making a GET 'safe' is a topical subject with the Google web acceleration inadvertently triggering side effects. without the safe tag, you have to assume that ever operation launches the nukes

<Arthur> Use GET if:

<Arthur> The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

uyalcina: if it's an extension, it calls attention to the use of the attribute; as opposed to the core handling of default (cannot assume safety)

Arthur: maybe we should point to a better URI for explaining safety
... maybe the wording the WebArch document is not all that clear without the rest of the document using it in many places and thus clarifying
... so maybe we should point to both the available good docs

Roberto: I'm perplexed by safety at the abstract level
... it makes sense to mark op to be safe on the actual endpoint
... after considering bindings, policies, implementations etc.
... but the stuff between the abstract interface and the actual service can affect whether the safety assertion can be trusted

<pauld> would prefer the method GET/PUT/POST/DELETE to be exposed

dorchard: I'd be in favor of binding safety more directly to GET

Marsh: dorchard will create a proposal, we can use chad
... we'll prolly have to do it in the f2f

<Marsh> ACTION: DaveO to ressurect option to indicate GET more directly. due, FTF. [recorded in http://www.w3.org/2005/05/19-ws-desc-minutes.html#action02]

JacekK: responding to roberto, it's about semantics on operations, they aren't only about schemas for messages but also about more semantics in the contract

kevinl: the primer has an example for safety, but that's not enough there, we also need URI style etc, so safety seems a bit small

<Arthur> safety should be a property of the interface since mulitple endpoints are alternates and it would be odd to have one alternate safe and one unsafe

Roberto: the users don't care about separating the abstract contract from the policy etc, it's one interaction

<uyalcina> -1 to Arthur

<Arthur> soap abstracts safety from http by have a webmethod which gets bound to the appropriate verb for http

Marsh: we'll close the discussion now
... I'd like to point out a few more issues we might want to get prepared for before the f2f
... not sure the async tf is going to bear on this

mep-related issues

Marsh: anybody has a proposal?
... glen, is the async tf bear on this issue?

GlenD: yes
... async tf is going to recommend a way to do that (support one-way mep in SOAP 1.2 in WSDL 2), we'll have a recommendation

Marsh: will it result in WSDL changes?

GlenD: not certain, doubtful, the extensibility hooks should be sufficient

Marsh: will hook this on async tf
... lc102 is directly related to async tf, right?
... the TF recommendations should allow us to close the issues quickly
... LC101, mixing binding on ins and outs?

kevin, glen: also related to async tf

Marsh: it seems outside what the TF is working on
... we need a proposal by f2f close if it's going to affect us
... is there interest in WSDL-only solution (non-Addressing dependent)?
... any volunteers?

kevin: we'll see how they in the ATF do, we don't seem to need a WSDL-only solution

Marsh: ok, we'll wait for the ATF's progress
... we have 17 issues now, we could actually make it 8-)

meeting adjourned

Summary of Action Items

[NEW] ACTION: DaveO to ressurect option to indicate GET more directly. due, FTF. [recorded in http://www.w3.org/2005/05/19-ws-desc-minutes.html#action02]
[NEW] ACTION: Umit to provide #none for Primer due: June [recorded in http://www.w3.org/2005/05/19-ws-desc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/05/19 16:40:00 $