WS Description WG -- 7 Dec 2006

<Jonathan> Yes, suppose so...

<TomJ> can't access conference on zakim

<asir> can't access conference on Zakim

conference code is WSDL

approval of minutes

minutes approved

AI Review

administrivia

Jonathan: arthur suggested to add canonicalization for WSDL1.1 component designators

Arthur: If the WG agrees, we should recommend to add a canonicalization to be consistent with WSDL2.0

Asir: we could open a formal issue to th WS-Policy WG ?
... I can open it.

<scribe> ACTION: Asir to open a WS-Policy issue and link it with CR80 [recorded in http://www.w3.org/2006/12/07-ws-desc-minutes.html#action01]

MTOM Description

Issue 82

<Jonathan> http://lists.w3.org/Archives/Public/www-ws-desc/2006Nov/0135.html

Jonathan: jason says that he would like to extend the rpc signature but agrees the suggestion is bad timing
... can we accept this response and leave the spec as it is?

TomJ: we do not prevent what he wants, toolkits may modify the rpc signature

RESOLUTION: close CR082 and mark it as accepted

CR092

<Jonathan> http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0017.html

Jonathan: CR092/CR092 is about soap usage that WSDL2.0/SOAP binding does not allow to describe
... I sent a partial list of soap1.2 functionalities that cannot be described with our soap1.2 binding

Tom: we should say that the soap1.2 fault details element will contain an element, but may contain other stuff that is not described

Jonathan: proposal is to add the list of SOAP functionalities that cannot be described and add tom comment
... can we close these two issues with this resolution ?

RESOLUTION: close CR92 and CR93 according proposal

Assertions that are not assertions

Jonathan: CR096 seems editorial

Arthur: I will check the source and let's move on

Jonathan: issue CR095 is about wsoap:header@element. Being of type QName, it prevents the #any value
... Why should we allow it?
... proposal is #any is not allowed as it has not a clear utility

<asir> +1 Jonathan's suggestion

Arthur: It seems that we are not generating message assertions. We need another assertion table
... we could also have one assertion table, with a "assertion type" column
... as a quick fix, I will add another table but I prefer to have one unique table that combines all current tables

Jonathan: arthur proposal for CR094 is to add another assertion table

RESOLUTION: CR094 closed with arthur proposal

back to CR095

Jonathan: #any is a no op.

RESOLUTION: CR095 is closed with no action, jonathan to answer to ram
... close CR096 by removing the cited assertion

Issue CR097

Jonathan: it seems that this assertion is redundant with schema checks
... the order of the desc. children is not captured by the schema. This assertion is about the order.

Roberto: we come up with this schema, looser than expected because of non determinism issues

Jonathan: proposal is close with no action

RESOLUTION: Close CR097 with no action

Issue CR098

http://www.w3.org/2002/ws/desc/5/cr-issues/#CR098

<Jonathan> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#Types-1300002

Jonathan: Is the cited assertion already covered by other assertions, as suggested?

<scribe> ACTION: Arthur to look at CR098 [recorded in http://www.w3.org/2006/12/07-ws-desc-minutes.html#action02]

Issue CR099

Jonathan: similar to CR098

<scribe> ACTION: Arthur to look at CR099 [recorded in http://www.w3.org/2006/12/07-ws-desc-minutes.html#action03]

Issue CR100

Jonathan: Import-0001 and Import-0070 seem to adress the same thing, unless any subtlety

Arthur: we should leave the text and retain only one of the two assertions.

RESOLUTION: Close CR100 by dropping Import-0001 assertion (but leaving the text)

<Arthur> I just committed the fix to CR094

Issue CR101

Jonathan: The three assertions seem redundant

Proposal is to keep the assertion in section 121900 and remove the other assertions

RESOLUTION: Close CR101 according this proposal

Issue CR102

Arthur: we should rewrite this assertion and remove the use of "imported components"
... we want to say that we import a namespace.
... proposal is to rewrite Import-0003 sentence and remove this assertion

RESOLUTION: close CR102 according proposal

Issue CR103

Tony: the second assertion is not complete. We should remove the second assertion and fix the wording.

Jonathan: do we want to remove the sentence or improve it?
... the proposal is to take the last sentence of the section 3.1.1.2 and move it to section 3.1.2

<Jonathan> reword = reference Schema-0016

Jonathan: in addition, remove the assertion Types-1300001 and rewording it to add a reference to Schema-0016

RESOLUTION: close CR103 according proposal

Issue CR104

RESOLUTION: Close Issue CR104 and remove Description-0024

Issue CR105

Jonathan: proposal is to remove assertion markup from 1204002

RESOLUTION: close CR105 by dropping InterfaceOperation-1204002

Issue CR106

Jonathan: drop InterfaceOperation-1204003

RESOLUTION: Close CR106 by dropping InterfaceOperation-1204003

Issue CR107

Roberto: we could test the case of two styles that are contradictory

Jonathan: but we rely on something external
... proposal is to close CR107 with no action and add a test case

RESOLUTION: close CR107 with no action

Issue CR108

<Roberto> 14: !unique => present <=> ! ! absent

<Roberto> 6: ! absent => unique

<Roberto> so they are logically equivalent, no?

<Roberto> oops, I mixed up the 14/6 labels

<Roberto> the first one I wrote is 6, the second one 14

<Roberto> I'd assert that they are equivalent and 6 should be removed, as it is the most poorly worded of the two

<scribe> ACTION: Amy to write a proposal for CR108 [recorded in http://www.w3.org/2006/12/07-ws-desc-minutes.html#action04]

- DRAFT -

WS Description WG

7 Dec 2006

Attendees

Contents