Web Services Description WG F2F

 

 

<Marsh> Good morning!

<Arthur> scribe: Arthur

<scribe> Chair: Hugo

<scribe> Meeting: WSD WG F2F, Sonic, Burlington, MA

<scribe> Agenda: http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0094

LC124

<hugo-proj> Dave's proposal for ignoreUnexpected: http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0116.html

dorchard: reviews ignoreUnexpected proposal

<dorchard> should be "unexpected" not "expected"

<pauld> 'hook' proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0122.html

glen: does this mean maxoccurs doesn't work

tony: you just take the first occurences up to the max then discard the rest

pauld: i'm slightly nervous about that

<scribe> Scribe: Arthur

tony: cites example from UDDI where mutliple first names were introduced

dorchard: a V1 processor would accept the first occurence of the the firstname and ignore the lang attribute, then ignore subsequent firstname occurences

tony: not a problem since V1 processor is only expecting one firstname

dorchard: may be a problem if the V1 processor was expecting the firstname to be in English but the actual firstname was Russian, then it would grab the Russian firstname

tony: the service should behave compatibly with V1 clients
... e.g. if V1 clients expect English first, then V2 services should put English first

pauld: what is the difference between David's proposal and Roberto's proposal

<Roberto> http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0119.html

roberto: I used different rules for unexpected content (which I misapplied in my example)
... david's proposal applies surgery to schema which violates UPA

<pauld> how we learnt to love UPA

roberto: schenma defines deterministic grammars

<TonyR> my response to Roberto's e-mail: http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0120.html

roberto: the other complexities of schema, e.g. wildcards, substitution groups, etc., should be alter the determinism of the gramar
... we could write the rule independently of the schema spec language, which is very complex

tony: we could specify what the surgery is
... when you hit the last tag you are expecting, then transition to a new state where you skip the rest of the content

uyalcina: what about <choice>? what happens with unknown elements?
... a document which was invalid for V2 might be "corrected" so it was valid for V1

<uyalcina> my concerns is that the relaxed algorithm will accept documents that are not valid for the second generation of the service.

arthur: the more lax processing allows the scenario where a V1 client might send invalid messages, which then a V1 processor would accept

pauld: that's ok because the WSDL accurately describes the V1 service, i.e. it will ignore unexpected content whether or not the client is a different version

hugo: umit, your concerns are more about the general behavior rather than the specific proposal

tony: i don't like the 3 rules at the end of david's proposal regarding <any>'s

amy: i wonder how complete the algorithm is. i like the general direction. i'd like to see the algorithm laid out in a very clear fashion since i'll need to implement it.
... i don't like we can complete this algorithm here.

hugo: paul will now present his "hook" proposal

<hugo-proj> Paul's proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0122.html

pauld: my original proposal included a schema processing style because i was not confident that v2s would be the ultimate choice
... i suggest we add a component property with 3 values: strict (ignore none), ignore unknowns, and ignore unexpected (the prefered alogorithm)
... see URL for details

tomj: i favour less flexibility in light of the publication schedule

<dorchard> +1 to Tom's concern about multi-places

pauld: i suggest we pick one

umit: i propose we just put it on <types>

<pauld> http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0122.html

umit: could we publish the algorithm as a note

hugo: yes
... the third proposal is a boolean v2s property

<hugo-proj> @ignoreUnknown proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0091

dorchard: v2s is one way to implement ignoreUnknowns

<pauld> chad, question: options for LC124

<pauld> chad, option 0: status quo

arthur: i suggest a property on the endppoint, whose value is a uri, and we define a uri for strict processing, and leave the definition of other uris to adjuncts or notes

dorchard: we should at least also define a uri for ignoreUnknowns

umit: i think <endpoint> is too late

<pauld> chad, option 1: ignoreUnknows, V2S, boolean

<pauld> chad, option 2: ignoreUnexpected, DO, boolean

<pauld> chad, option 3a: styleURI (Paul's hook)

<pauld> chad, option 3b: styleURI + flag (Paul's hook)

<alewis> chad, option 0: nothing at all

<RebeccaB> chad, options?

<pauld> chad, drop option 3a

<pauld> chad, drop option 3b

<pauld> chad, option 3: Paul's hook

<alewis> vote: 3, 0

vote: 3, 2, 0, 1

<ChadFan> vote: 2, 0

<Allen> vote: 2,3

<Roberto> vote: 2, 3, 0

<anish> vote: 0

<TonyR> vote: 3, 2, 0

<dorchard> vote 1,2

<hugo-proj> vote: 3, 1, 0

<dorchard> vote: 1,2

<youenn> vote: 2, 3, 0

<RebeccaB> vote: 0,3,2

<umit> vote: 3, 0

<TomJ> vote: 0, 3, 2

<Marsh> vote: abstain

<pauld> vote: 2,3

<JacekK> vote: abstain

<pauld> chad, count

<chad> Question: options for LC124

<chad> Option 0: nothing at all (3)

<chad> Option 1: ignoreUnknows, V2S, boolean (1)

<chad> Option 2: ignoreUnexpected, DO, boolean (5)

<chad> Option 3: Paul's hook (5)

<chad> 16 voters: alewis (3, 0) , Allen (2, 3) , anish (0) , Arthur (3, 2, 0, 1) , ChadFan (2, 0) , dorchard (1, 2) , hugo-proj (3, 1, 0) , JacekK () , Marsh () , pauld (2, 3) , RebeccaB (0, 3, 2) , Roberto (2, 3, 0) , TomJ (0, 3, 2) , TonyR (3, 2, 0) , umit (3, 0) , youenn (2, 3, 0)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: Eliminating candidate 1.

<chad> Round 3: Eliminating candidate 0.

<chad> Round 4: Eliminating candidate 2.

<chad> Candidate 3 is elected.

<chad> Winner is option 3 - Paul's hook

<pauld> chad, details

<dorchard> I can live with it on interfaces.

amy: i propose to just put a uri on <interface>
... we need to specify inheritence, e.g. inherit the setting

<RebeccaB> +1 on Marsh's comment

jonathan: i like it on the endpoint

pauld: BT publishes wsdl without <endpoint>

<Zakim> pauld, you wanted to be on there just in case

<Marsh> I think this can either be phrased as a QoS issue (details of an endpoint), or as a fundamental schema language issue (types/interfaces).

arthur: we can associate the property with the operations and faults defined in the interface

<Marsh> The former sounds scary at this point in our process.

<Marsh> Oops, I mean the latter...

roberto: i don't think Jonathan's analogy with character encoding is good since this property applies to data binding
... i think it should be defined on the <xsd:schema> element as an attribute

pauld: or on <xsd:element>

umit: i don't like putting on individual elements

<dorchard> Roberto, do you mean <xs:import wsdl:flag/>?

<Roberto> no, <xsd:schema wsdl:flag/>

dorchard: i don't like putting it on <endpoint>
... i don't like it on schema since this is a wsdl concept (but <types> is ok)

dorarch: i like interface but couldn't see a clean way to do it

arthur: what about applying it to interface by associating it with its operations and faults

<alewis> chad, new vote

<chad> new poll

dorchard: i like that since we could have 2 interface definitions

<alewis> chad, question: what is the preferred location of the ignoreUnknowns attribute/property

<alewis> chad, option 1: endpoint

<alewis> chad, option 2: interface

<alewis> chad, optiion 2: interface (with/without inheritance)

<alewis> chad, option 2: interface (with/without inheritance)

<alewis> chad, option 3: types

<Marsh> oops, muted

<Marsh> I like 1

<alewis> chad, option 4: xs:schema

hugo: we have 1) endpoint, 2) interface 3) interface w/o inheritance, 4) types, 5) schema
... indicate who likes it and who dislikes it
... vote for like/dislike/can't live with it

1) endppoint: 8/3/1

2) interface: 2/8/2

3) interface w/o inheritance: 10/3/2

<Marsh> I really have a problem with it on types

4) types 5/10/1

<Marsh> I really have a problem with it on schema

5) schema 5/4/2

<Marsh> yes, sure

<Marsh> though I would suck up almost anything to resolve this quickly.

break for 15 minutes, back at 10:53

resuming now

<pauld> voting on the whitboard: http://www.flickr.com/photos/psd/27569776/

hugo: let's eliminate 2) interface w inheritance and 4) types

darth vader has joined

<pauld> chad, options?

<pauld> chad, new vote

<chad> new poll

<pauld> chad, question: what is the preferred location of the ignoreUnknowns attribute/property

<pauld> chad, option 1: endpoint

<pauld> chad, option 4: xs:schema

<pauld> chad, option 0: status quo

<dorchard> status quo sucks compared to doing types. It would be way better to have 1 place than 0 places.

<RebeccaB> chad: options?

<pauld> chad, option 3: interface without inheritance

<pauld> chad, options?

hugo: champions will review their proposals

Jonathan: there is no attempt in MSFT products to alter the schema language
... the granularity is that of a toolkit and different toolkits exhibit different behavior so we can describe this as a policy of the endpoint
... adding it to types is a bad idea since it applies to all type systems, interface has inheritance problems

Arthur: interface is intermediate between endpoint and schema so its a good compromise

<Zakim> Marsh, you wanted to challenge Arthur's mischaracterization of my position.

Arthur: making it endpoint dependent would hamper interop
... putting it on schema introduces specification difficulty due to the complexity of schema
... the interface w/o inheritance proposal has no inheritance problems

Roberto: I am proposing schema + endpoint so I won't repeat Jonathan's defense of endpoint
... this belongs on schema because of the close association with data binding

<uyalcina> I have a concern about applying a rule to certain set of interfaces. IMO, a toolkit will be dealing with the WSDL interface and types in its entirety, including imports/includes. Therefore, I prefer a solution which applies to the entire component model.

Roberto: putting it on schema associates the processing with the namespace so you don't get different behavior in different contexts

<Marsh> Marsh: Per endpoint without indication in WSDL is hampering interop today. Having a marker on endpoint keeps close to existing implementations, but helps interop by signalling what behavior should be expected.

hugo: let's go around the table with 1 minute comments

tony: no strong preference but i like endpoint or interface

tom: we should stay with the status quo and time is runnning out

<uyalcina> The problem does not belong to the endpoint, but it is an acceptable workaround since it will deal with multiple schema documents, import/includes.

youenn: endpoint is good, interface is messy, don't understand mixing schema and endpoint values

pauld: concerned about interface becaus ewe don't have text, i don't like endpoint because it is a data binding issue, i like schema because it is a schema problem

amy: any place is ok, in response to tom, we need to satisfy this requirement or we'll get LC comments

<TomJ> I don't think that we have got sufficient LC comments in the first go round that we must deal with this in this manner

anish: i have concerns but i am sympathetic to paul's requirements since he is the only customer in this good, i want to go to LC asap and not add incompletely thought out proposals
... i prefer status quo but could live with other options

rebecca: this idea is not fully baked, there is no convergence of ideas, lots of problems to resolve, i prefer status quo but next is interface, followed by endpoint and schema

<pauld> we closed this issue with an AI to engange the schema WG on this work. This issue resulted from our inability to deliver a joint TF.

<uyalcina> I do agree that the problem is with the schema, but introducing the markup at the schema will end up introducing dual processing modes into the same component model which is not desirable.

i believe this is a schema problem, putting it in interface would result in a mixture of processing modes, so putting it in endpoint is the best alternatives

roberto: i prefer schema + endpoint, status quo would miss a good reason for using wsdl 2.0

glen: this is important and i prefer a simple boolean option, extensibility is too complex, in the absence of a simple solution i prefer status quo, i really dislike the interface approach

dorchard: i prefer a simple boolean option, on the types, ignore unknowns

<uyalcina> you can publish empty endpoints without deploying them, we introduced the functionality into WSDL 2.0

dorchard: since that option is off the table, i think putting in schema is wrong, endpoint is a terrible place for it since people will publish wsdl w/o endpoint, i therefore prefer interface w/o inheritance, followed by schema. i'm opposed to status quo

hugo: i am worried about interface and schema since we have no text, at least we have text for endpoint and i am convinced by jonathan's arguments
... either status quo or endpoint is the only way to go

jonathan: i concede that this could be a schema annotation, in the absence of a solution, i favour status quo and pursuing this discussion in parallel
... there could be another deliverable

<anish> big +1 to jonathan

pauld: process question: how to soap do mtom?

anish: we were rechartered

<RebeccaB> That's what I always assumed would happen if we went with the status quo

charleton: n/a

allen: i am against status quo but i am intrigued by jonathan's proposal. my preference is endpoint

hugo: jonathan's has proposed status quo for the spec + another deliverable

jonathan: we need agreement from ac, we seem to be down to status go if we want to go to LC today

<hugo-proj> chad, new poll

<chad> new poll

<hugo-proj> option 0: status quo

jonathan: if this a schema extension then it has less impact to wsdl

<hugo-proj> chad, option 0: status quo

<hugo-proj> chad, option 0a: status quo + extra deliverable

<hugo-proj> chad, option 1: hook at endpoint level

<hugo-proj> chad, option 3: hook at interface level w/o inheritence

<hugo-proj> chad, option 5: hook at schema def level

<hugo-proj> chad, option 5a: hook at schema def level + endpoint level

<RebeccaB> chad: options?

<dorchard> vote: 3, 5, 5a

vote: 0a, 3, 5, 5a, 1, 0

<RebeccaB> vote: 0a,0a,0a,3,1

<alewis> vote: 5a, 5, 3, 1, 0a

<Allen> vote: 1, 0a, 3

<uyalcina> vote: 0a, 1

<hugo-proj> vote: 0a, 0, 1, 3, 5a, 5

<bijan> vote: 0a, 5, 3, 1

<youenn> vote: 1, 5a, 5, Oa

<TomJ> vote: 0, 0a, 1 3

<TonyR> vote: 3, 1, 0a

<youenn> vote: 1, 5a, 5, 0a

<pauld> vote: 5, 5a, 1, 0a

<anish> vote: 0a, 0

<uyalcina> vote: 0a, 1, 0

<youenn> vote: 1, 5a, 0a

<GlenD> 0a, 0

<RebeccaB> vote: 0a,0,3,1

<Roberto> vote: 5a, 1, 0a, 5, 0, 3

<GlenD> vote: 0a, 0

<charlton> chad

<hugo-proj> chad, votes?

<bijan> I have no comment, thanks though

<bijan> I think I understand what I prefer, but nothing really to add

<charlton> chad vote: 0a, 1, 0

<Marsh> vote: 0a, 0

<anish> vote: charlon: 0a, 1, 0

<charlton> thanks anish

<alewis> chad, count?

<chad> Question: unknown

<chad> Option 0: status quo (1)

<chad> Option 0a: status quo + extra deliverable (9)

<chad> Option 1: hook at endpoint level (2)

<chad> Option 3: hook at interface level w/o inheritence (2)

<chad> Option 5: hook at schema def level (1)

<chad> Option 5a: hook at schema def level + endpoint level (2)

<chad> 17 voters: alewis (5a, 5, 3, 1, 0a) , Allen (1, 0a, 3) , anish (0a, 0) , Arthur (0a, 3, 5, 5a, 1, 0) , bijan (0a, 5, 3, 1) , charlon (0a, 1, 0) , dorchard (3, 5, 5a) , GlenD (0a, 0) , hugo-proj (0a, 0, 1, 3, 5a, 5) , Marsh (0a, 0) , pauld (5, 5a, 1, 0a) , RebeccaB (0a, 0, 3, 1) , Roberto (5a, 1, 0a, 5, 0, 3) , TomJ (0, 0a, 1, 3) , TonyR (3, 1, 0a) , uyalcina (0a, 1, 0) , youenn (1, 5a, 0a)

<chad> Round 1: Count of first place rankings.

<chad> Candidate 0a is elected.

<chad> Winner is option 0a - status quo + extra deliverable

<charlton> anish, i guess i have a new name

<alewis> chad, details?

<Roberto> chad, details

<dorchard> It won't be consensus if people object

<charlton> are there objections to 0a?

<dorchard> BEA systems objects to 0a.

<charlton> i know there are for 0 but given my phone troubles didn't catch whether any were raised for 0a

<charlton> ok

hugo: we'll do a formal vote now

pauld: i suggest this group submit a summary of this discussion to the schema wg
... we should express this as web services requirements on schema

<pauld> chad, hi

<Roberto> I agree to capturing the discussion for the benefit of other groups (or new members of our group) who are interested in it

question for the vote: Do you accept status quo as the resolution of LC124?

bea - no

bt - no

canon - no

ca - yes

cyclone - absent

deri - absent

ibm - yes

sanjiva - absent

iona - yes

macromedia - yes

microsoft - absent

oracle - yes

rouge wave - absent

sap - yes

sonic - absent

sun - no

tibco - yes

u maryland - abstain

w3c - yes

adobe - yes (unsure of good standing)

results: yes = 8(9) no = 4, abstain = 1

pauld is the originator of LC124

dorchard is likely to file a formal objection, possibly pauld, possibly roberto

<dorchard> BEA is likely to file a formal objection, unless something miraculous appears in WSDL 2.0 that provides some solution in this space.

amy: the proponents of ignore unexpected should come back with a more detailed proposal

umit: +1 to amy

hugo: i'd like to close the discussion on LC124

<uyalcina> I propose we publish a note just like the mediatypes document the wg has produced.

pauld: i would prefer to write a summary that was supported by the wg rather than writing a minority objection

Amy and Roberto issue on the schema

<pauld> ACTION: pauld to write a proposal for a working group report for requirements for schema evolution following closure of LC124 [recorded in http://www.w3.org/2005/07/21-ws-desc-minutes.html#action01]

amy: the schema does not enforce the order of the top-level elements which is required by the spec
... the existence of allowed extension elements prevents writing a deterministic grammar
... Roberto and I have text. This is editorial.

<pauld> adding a wrapper element is unacceptable for WSDL, though that's the only schema friendly work-round we now impose on all our users for their data. what we want is an ignoreUnknowns on the top of our schema :-)

LC76d

hugo: we closed LC76d by adding wsoap:header which includes mustUnderstand
... we discussed removing wsoap:mustUnderstand
... we hit a problem about allowing the attribute in the content model

<hugo-proj> [[

<hugo-proj> Schema elements intended for use as SOAP headers MUST be extensible with SOAP attributes.

<hugo-proj> --- v2 ---

<hugo-proj> Schema elements used as SOAP headers in wsoap:header declarations MUST be extensible with SOAP attributes.

<hugo-proj> --- v3 ---

<hugo-proj> Schema elements used as SOAP headers in wsoap:header declarations with a @wsoap:mustUnderstand value of "true" MUST allow the soap:mustUnderstand attribute with the value of "true".

<hugo-proj> ]]

anish: friendly amendment to V3 to also allow the value "false"

<hugo-proj> Anish's proposal: Schema elements used as SOAP headers in wsoap:header declarations with a @wsoap:mustUnderstand value of "true" MUST allow the soap:mustUnderstand attribute.

<dorchard> +1 to anish

<dorchard> Hugo, it's actual "with a @wsoap:mustUnderstand MUST allow ..."

<uyalcina> I would like to add a clarification to the spec but remove the wsoap:mU attribute. This is a problem for using any element which would appear as a header regardless of the attribute.

<uyalcina> I propose we add a clarification regardless of what we do with wsoap:mU and then vote on mU attribute.

<hugo-proj> Proposal: change "{mustUnderstand} REQUIRED. A xs:boolean indicating if the SOAP header block MUST be decorated with a SOAP mustUnderstand attribute information item." into "{mustUnderstand} REQUIRED. A xs:boolean indicating, when set to "true", that the SOAP header block MUST be decorated with a SOAP mustUnderstand attribute information item with a value of "true"."

<charlton> lakeside view? see the lake one day, see it not the other

<pauld> chad, new poll

<chad> new poll

<pauld> chad, question: options for LC76d

<pauld> chad, option 0: Status Quo

<pauld> chad, drop option 0

<pauld> chad, option 1: a schema element used as a SOAP header MUST be extensible with SOAP attributes

<pauld> chad, option 2: a schema element used as a SOAP header in wsoap:header declarations MUST be extensible with SOAP attributes

<hugo-proj> chad, new poll

<chad> new poll

<Roberto> /me

<Roberto> Keep movin', movin', movin'

<Roberto> Keep movin', movin', movin'

<dorchard> what are the options?

hugo is writing options on whiteboard as follows:

1a error if conflict with schema def

1b SHOULD allow attribute extensibility on schema decl of SOAP headers

1c same as 1b but MUST

1d same as 1b for SOAP attributes only

1e same as 1d but MUST

plus all the above as 2 with removing wsoap:mustUnderstand

<dorchard> I vote for keeping mU, but don't care about MUST/SHOULD/etc.

<dorchard> If roberto and I can live with 1a, why not vote on that?

<dorchard> I'll live with whatever option in #1 that roberto can live with.

straw poll: who would like to keep mustUnderstand?

yes = 5, no = 8, abstain = 1

yes = 5, no = 8, abstain = 2

any objections to removing mustUnderstand?

BEA objects

Roberto can live with 1a

hugo: Are there any objections to closing the issue with 1a?

no objections.

<dorchard> Hugo, nice job getting to consensus.

<scribe> ACTION: Editors of Part 2 to implement 1a. [recorded in http://www.w3.org/2005/07/21-ws-desc-minutes.html#action02]

Break for lunch. Resume at 1:45pm.

<Marsh> yay!

<anish> indeed nice job getting consensus

<sanjiva> guys can someone give me the conf code?

<Allen> Sanjiva, its wsf2f

<sanjiva> Allen: Thanks!

<Allen> Lunch will be over at 1:45 Boston time.

<sanjiva> oh u guys r @ lunch?? oh ok .. will call l8r then :)

<sanjiva> thanks

<Marsh> Does calling in for lunch count towards Good Standing?

<Marsh> Sounds rather zen.

<Roberto> Scribe: Roberto

<pauld> options on the whiteboard: http://www.flickr.com/photos/psd/27592009/

anish pointed out the text in the spec was incorrect

hugo: what it meant to say is that when wsoap:mustUnderstand is true, soap:mustUnderstand must be set to true

<hugo-proj> Proposal:

<hugo-proj> {mustUnderstand} REQUIRED. A xs:boolean. When its value is "true", the SOAP header block MUST be decorated with a SOAP mustUnderstand attribute information item with a value of "true". Otherwise, no constraint is placed as to the presence and value of a SOAP mustUnderstand attribute information item.

anish: last statement must be reworded (editorially) so that it allows contraints to appear in the schema

no objections to adopting hugo's proposal

<hugo-proj> [[

<hugo-proj> {mustUnderstand} REQUIRED. A xs:boolean. When its value is "true", the SOAP header block MUST be decorated with a SOAP mustUnderstand attribute information item with a value of "true". Otherwise, no additional constraint is placed on the presence and value of a SOAP mustUnderstand attribute information item.

<hugo-proj> ]]

Resolution: LC76d closed by accepting Hugo's proposal

hugo: last call starts when we publish the documents

marsh: close it September 27th (two days before the Sept f2f)

hugo: close it on the 26th (Monday)
... going to last call with four documents: core, adjuncts, primer, soap 1.1 binding; all reflecting the decisions made in this meeting
... with last call ending on Sept 26

(much discussion about the date...)

hugo: date amended to Sept 19th
... formal vote for going to last call
... question is: do you agree to publish the four documents above as last call with review ending on sept 19

bea - yes

bt - yes

canon - yes

ca - yes

<Marsh> proposes friendly amendment - that the question be read with a fanfare of trumpets...

ibm - yes

iona - yes

macromedia - yes

microsoft - yes

oracle - yes

roguewave - yes

sap - yes

<Marsh> note oracle by proxy...

sonic - yes

sun - yes

tibco - yes

w3c - yes

hugo: congratulations, we are in last call (again)!

<Marsh> RESOLVED: Motion carries unanimously!

Alternative schema languages

marsh: bijan did work on the document, html version available

<hugo-proj> Alt schemas document: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/altschemalangs.html?rev=1.2&content-type=text/html;%20charset=utf-8

(reviewing the document...)

alewis: bad markup in section 3.1

<anish> for the minutes: Oracle did want to vote yes and had designated my esteemed colleague from IONA (who is sitting next to me) as proxy

marsh: section 2 is new
... my preference is to publish it as a note
... we can republish it later if somebody finds errors in it

alewis: let's do it as a note

marsh: it's better to publish it concurrently with last call, so that people will know where the missing appendix went

alewis: points out potential confusion in publishing notes and LCs at the same time
... leave some delay in between so that people won't get confused

marsh: we haven't published this note before, so it's a first publication, which requires director's approval

alewis: volunteers to do some cleanup

hugo: points out that the "Abstract" section is empty

<alewis> ACTION: amy to write abstract for alt schema languages and to do some cleanup under jonathan's direction [recorded in http://www.w3.org/2005/07/21-ws-desc-minutes.html#action03]

<alewis> ACTION: editors of note to add references to wsdl documents [recorded in http://www.w3.org/2005/07/21-ws-desc-minutes.html#action04]

RESOLUTION: publish document as a wg note after some editorial work

hugo: done with yesterday's agenda

Common schema structures document

<pauld> http://tinyurl.com/apkjz

hugo: paul reformatted his document as a wg note

umit: there is a proposal in the AC for a working group on this subject

paul: as of today, there is no note and there is no working group
... wants something to address the problem, i.e. the inconsistencies in describing data structures in schema
... the document gives that working group (if there is one) something to point to

marsh: we need to decide the path we want this document to take
... options are: one-time note, more polished doc (like alt media types note), no doc at all

paul: took comments from people, so what are my options if I want to work outside the wg?

marsh: this group is not under the new patent policy
... even if we were, if this document is not on the rec track, we wouldn't be under ip obligations

paul: working groups may be uncomfortable in using this note

marsh: it doesn't make any difference, as long as you don't impose RAND terms on the document if published separately

note: there are no lawyers in this working group

umit: if there is a wg, would like not to do too much work on this doc

paul: timing issue; need something published quickly or do nothing and wait for the wg to start
... there is a risk the wg won't happen
... would like to take comments and incorporate input from people

roberto: feels that if the wg doesn't happen, we won't be able to keep the document as one-time only, we'll have to evolve it

paul: wg is likely to happen; also, document was never meant to be comprehensive
... provide LCD functionality

<uyalcina> Let me make myself clear. If there is a working group, i don't want to carry a parallel effort in both places.

hugo: in the status section, we can say that we don't intend to update the document (with some justification)

umit: when will the AC make a decision?

paul: in August

<pauld> http://www.w3.org/2005/07/ws-databinding-charter.html

roberto: can't we postpone this discussion to the first meeting in September?

paul: except that if we publish it now, that charter could be changed to cite our note

hugo: copyright on the document is already to w3c; as for IP, there won't be any disclosure at the time of publication
... not necessary to be under TR to be in a charter

paul: Philippe told me he prefers a member submission
... there are IP implications in making a member submission

arthur: didn't see anything very original in this document, so doesn't understand IP issues
... prior art for data binding in various languages

umit: gets questions on why our wg is doing this

paul: this work predates the schema workshop and the wg

marsh: reasonable to publish this kind of material as a note (even just for archival purposes)

roberto: would like some serious analysis of the content to make sure it works well with existing data binding technologies

paul: you're looking at it with product eyes
... aim was to raise the LCD slightly

roberto: doesn't want to see antipatterns being published in a note

umit: there is a paper with schema patterns

paul: we have a lot of experience; LCD schema works well with (list of implementations...)
... 19 different implementations

<charlton> +1 to roberto - we shouldn't publish such content in a note or as part of the spec

paul: what works well in all of them is xs:string and xs:sequence
... that would make for a very short note

tomj: suggests not publishing as a note and have it as a member submission by BT

paul: people have shown interest

marsh: we don't need to publish the document to hand it over to the other group, say in September

arthur: if the document has to be the product of the wg, we need to allocate time to it

<sanjiva> My position: this has nothing to do with us and we should have no role in it

<Marsh> Two things this WG needs to decide: Do we want to allocate resources (agenda time) to this topic?

<Marsh> If yes, do we want to publish the results in some form?

<Marsh> (Third decision, don't necessarily need this today) If yes, what form/status?

arthur: the subject matter is valuable, but is it our mission?

paul: proposes to take comments, incorporate them, then decide whether to publish based on contents and status of the new wg

<sanjiva> I don't think it makes sense to do that .. this is clearly out of scope for this WG IMO.

<sanjiva> That is not a statement about the utility of the work .. this topic got discussed in soapbuilders nearly 4-5 years ago even and its great to see it real. But not in this WG.

marsh: will not allocate time for this on the agenda until September

hugo: any objections to closing the discussion for now and reconsider it later in September?

no objections

hugo: 15 minutes break (till 3:25pm)

Resolution of formal objections

<scribe> ACTION: amy to withdraw Tibco's participation from the formal objection on the ONR [recorded in http://www.w3.org/2005/07/21-ws-desc-minutes.html#action05]

<hugo-proj> Discussing: http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0376.html

<scribe> ACTION: arthur to review the status of IBM's formal objection to the ONR [recorded in http://www.w3.org/2005/07/21-ws-desc-minutes.html#action06]

<scribe> ACTION: jonathan to review the status of Microsoft's formal objection to the ONR [recorded in http://www.w3.org/2005/07/21-ws-desc-minutes.html#action07]

<hugo-proj> Discussing: http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0371.html and http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0375.html

glen: proposal is to make f&p optional and add compositors to the optional part

<charlton> do we have a URL to this proposal?

glen: doesn't find the reasons for IONA's withdrawal from the formal objection compelling enough

<RebeccaB> http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0106.html

<charlton> i think this is it

<charlton> http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/0069

roberto: Sun finds the compromise proposal promising

<charlton> i support the compromise proposal in concept

marsh: adding compositors would be even more objectionable than what we currently object to

<RebeccaB> IONA doesn't like the compromise

marsh: would accept compositors if we published f&p in a note

<Arthur> fyi: WS_Policy ftp://www6.software.ibm.com/software/developer/library/ws-policy.pdf

<Arthur> here's the IP statement: BEA Systems, IBM, Microsoft, SAP, Sonic Software, and VeriSign (collectively, the "Authors") each agree to grant you a license, under royalty-free and otherwise reasonable, non-discriminatory terms and conditions, to their respective essential patent claims that they deem necessary to implement the WS-Policy Specification.

arthur: Sonic is one of the authors of ws-policy, so why is Sonic objecting to it?

glen: we love ws-policy; we are objecting to the incorrect process that was used to shoot down this proposal

arthur: it was a long time ago
... there is a lot of overlap between f&p and ws-policy, which is now licensed under very favorable terms

glen: ws-policy is not quite like f&p
... usage patterns are not very well-defined
... no connection to soap f&p
... suggested compromise at last year's policy workshop

paul: if ws-policy was at w3c would f&p and compositors go away?

glen: there still needs to be a way to express f&p settings using ws-policy

paul: bt is concerned about using ws-policy for publishing services
... spec is not under an umbrella of an organization we can influence

glen: need the ability to soap properties as defined by set soap bindings

<Arthur> note the WS-Policy authors: Authors Siddharth Bajaj, VeriSign Don Box, Microsoft Dave Chappell, Sonic Software Francisco Curbera, IBM Glen Daniels, Sonic Software Phillip Hallam-Baker, VeriSign Maryann Hondo, IBM Chris Kaler, Microsoft Dave Langworthy, Microsoft Ashok Malhotra, Microsoft Anthony Nadalin, IBM Nataraj Nagaratnam, IBM Mark Nottingham, BEA Hemma Prafullchandra, VeriSign Claus von Riegen, SAP Jeffrey Schlimmer (Editor), Microsoft Chris Sharp, IBM

glen: would like to see a description of how to write ws-policy and get soap binding properties to be set

<pauld> wonders if WS-Policy is plug replaceable for F&P and what happens when we're in a world when we have both?

rebecca: concurs with glen and made the same point at the schema workshop

paul: we didn't have addressing in wsdl and we abstracted it out via extensibility

glen, amy, umit: disagree

scribe: the MEP task force didn't go there

paul: with f&p we followed a different route
... we produced a rival technology to an existing spec

glen: no, we needed a way to express in WSDL things that are in the soap rec
... recalls argument on whether f&p should only go in the soap binding and not in the abstract

alewis: sees a proposal to remove f&p altogether, which would hardly satisfy the objectors
... also, equating policy and f&p is incorrect
... the f&p model is very well defined and part of the wsdl component model
... the fact that properties are externally defined makes it hard to do much with properties whose name you don't recognize
... but at least they are part of the model

<pauld> remains unconvinced that if WS-Policy was a W3C spec, F&Ps would exist at all in WSDL 2.0

arthur: the policy spec has compositors; the objection is that compositors should be added to WSDL but I don't understand why you want to reproduce that work here
... why not define a WSDL extension that uses ws-policy compositors?

glen: hard to make progress without Oracle in the room
... moreover we need to talk to the powers that be

<Zakim> pauld, you wanted to provide a suggestion

paul: if ws-policy existed in the w3c, would you give up f&p?

<pauld> ack ack ack

Test assertions document and test suite

paul: no

arthur: (pointing at the test suite in CVS)
... 3 components to the test suite
... 1) documents, good and bad
... all documents are schema-valid

<charlton> i'm off to another meeting for a few - cu later all

arthur: about 20-30 test cases
... about 20-30 test cases
... would like every constant, etc. to be in at least one test case
... as for bad ones, would like for each rule in the spec at least one test case that violates it

alewis: can we as a wg say that to call an implementation conformant you have to pass the test suite?

hugo: how do you check, for good tests, that the correct messages are produced?

arthur: 2) messages (second type of component of the test suite)
... 3) collections of messages that correspond to a given MEP
... to do (2) we'll have to write a tool that generates messages
... there are already tools to capture message traffic
... would like to host services that folks can test against

paul: xml core and schema have '000s of documents, but are not that useful

arthur: write xpath to find all tests that test a certain feature, as identified by its declaration in the wsdl schema

<pauld> lack of metadata over the purpose of each test being the issue

arthur: in the schema spec, they gave a unique id to every rule
... tools can report what rule(s) a bad schema violated
... would like to do the same thing for our spec

alewis: suggesting that all MUSTs and SHOULDs should be tagged
... will introducing the markup change the visual layout, insert paragraphs, etc.?

arthur: other option to do it internally, but not show the assertion names in the normative spec

<pauld> pauld: so you're looking at identifying assertions and *embedding* them in the spec

arthur: having assertions in the spec is not helpful because in order to update the you have to rev the spec
... it's better if they are close to the tests, rather
... analogy with Z, that is in the spec but invisible
... it's important to provide standard names to be used by validators when reporting errors

can we use Z as the assertions?

arthur: would like the Z to refer to the ids

alewis: ask to surface something that will provide common identifiers to be used by all implementations

arthur: would like hyperlinking from the error messages to the spec

paul: could make everything a linkable paragraph

alewis: informative parts should not be linkable

arthur: would like the group to agree that the spec should contain stable ids for each assertion

tomj: fully supports arthur's proposal

<TonyR> omnes: acclaims idea

meeting adjourned