Web Services Resource Access Working Group Teleconference -- 05 Nov 2009

<trackbot> Date: 05 November 2009

<asoldano> bob, I can here worse than before..

<Yves> still bearable? or difficult to understand

<dug> we moved the mic - is it ok or do we need to move it back?

<asoldano> very diffcult to understand

<dug> better? for bob

<asoldano> i just here laught now ;)

<Katy> I can hear him ok but there's some crackling

<dug> can you hear bob?

<Katy> yes

<Bob> scribe: Sreed

Bob: Approval of the agenda

Asir: New issues they are not on the agenda

Bob: Agenda is agreed
... Approval of the minutes from the 27th Oct - accepted
... Next F2F is scheduled on Jan 26th to 28th hosted by Fujitsu

<asoldano> any chance you can move the mic where it was before?

<asoldano> thanks gpilz

<Katy> that does sound better

<asoldano> at least I can hear bob better

<Katy> :o) me too

Bob: Proposed F2F in Mar 24th to 26th OR week of Mar 15th

Proposed F2F Mar 30th to April 1st

Bob: Can we do that in France Sophia
... Mar 30th to Aprl 1st - Oracle is going to check if they can host the meeting

Ram: Will check if possiblity of MSFT can host in bay area

<scribe> ACTION: Gil to check the possiblity of Oracle hosting the F2F in Mar 30th to Apr 1st [recorded in http://www.w3.org/2009/11/05-ws-ra-minutes.html#action01]

<trackbot> Sorry, couldn't find user - Gil

Bob: We will address the issues that already been opened & also to open the future issues as possible

Asir: We don't how to address is the 40+ issues that has been opened now

<Katy> Yves - pls could you allow access to W3 from IP 195.212.29.92 ? thanks

gpliz: we support the same -with Bob no. of WS Fragment issues needs to be raised need time unti mid-night monday

Bob: Agreed morotorium mid night monday
... Moving to new issues 8124 - http://www.w3.org/Bugs/Public/show_bug.cgi?id=8124
... New issues has been sorted out - marked "E" will sent email to accept
... Other category is "L"

<Ram> I have not reviewed the new issues marked as "L".

Bob: Sorting out the issues into "E" & "L"
... We will have moratorium on monday

Ram: New issue on this morning

<asir> can we record how we plan to categorize E and L?

<asir> Bob mentioned taht we would categorize issues as now, E or L in the WG con call scheduled for Tue Nov 17th

<Katy> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/0065.html

Issue-7912

Asir: General flow is ok - bottom of the proposal 3rd part two sentences discuss about WSDL semantics
... what is the basis adding new semantics

<Bob> see above

<Bob> discussion concerning the contents of the following two sentences in the proposal

<Bob> If a Feature WSDL is abstract, then the

<Bob> endpoint of the Endpoint WSDL MUST be used for the feature operations. If

<Bob> a Feature WSDL defines a concrete endpoint, then this endpoint MUST be

<Bob> used for the feature operations.

Bob: Except of two sentences is there an agreement for others addressed

Asir: 8031 is not connected to this

<Bob> folks are in agreement with all but the last two sentences of the proposal

<Zakim> asir, you wanted to answer dug

Asir: Why can't we add recommendation sufficient information

gpilz: Why recommendation

<asir> This is what MEX is for. Welcome to MEX!

gpilz: it is important that we have high level points discussed

<dug> What does it mean if the WSDL is abstract?

<Bob> proposal for sentence in contention Nr. 2

<dug> YES!

<Bob> Normal WSDL semantics apply

<gpilz> If a Feature WSDL defines a concrete endpoint, Normal WSDL semantics apply.

<gpilz> If a Feature WSDL is abstract, then the endpoint of the Endpoint WSDL MUST be used for the feature operations. If a Feature WSDL defines a concrete endpoint, normal WSDL semantics apply.

<Bob> where or where has my working group gone, oh where or where can they be?

<Bob> with my patience cut short nd their hair cut long, oh where are where can they be?

Bob: Second sentence posted by gpilz is there any objection

<asir> agree with Martin the term 'Feature' is not defined

<gpilz> the proposal says "An endpoint MAY choose to expose the WSDL of the policy defined feature by using the http://schemas.xmlsoap.org/wsdl/ dialect and the dialect identifier of the target namespace of the feature."

<Bob> ok with this? If a Feature WSDL defines a concrete endpoint, normal WSDL semantics apply.

<Bob> now thisIf a Feature WSDL is abstract, then the endpoint of the Endpoint WSDL MUST be used for the feature operations.

Asir: If WSDL abstract it is

<asir> you can say .. feature WSDLs are concrete (that is carries binding, service and endpoint info)

Bob: Katy will reword

Martin: EPR for the future WSDL should we need to have the combinations - Endpoint WSDL 3 possibilities

<Katy> q

<Katy> The feature WSDL MAY just provide the abstract aspects of the

<Katy> feature for the endpoint. A Feature WSDL may alternatively define a different concrete endpint.

Bob: we have some concrete words put forward by Katy

<asir> Plain simple ...

<asir> A feature WSDL MAY just provide portType and binding desciprtions of the feature for the endpoint.

Bob: Any objections to Asir text

<Katy> A feature WSDL might not provide a concrete endpoint in which case the consumer MUST use the concrete aspects of the endpoint's WSDL

<dug> When a Feature WSDL does not provide a concrete endpoint, the consumer MUST use the concrete aspects of the endpoint's WSDL.

Bob: Do we have any objections? Is the second sentence is necessary

<dug> The Feature WSDL, the WSDL associated with these implicit operations, can be annotated to indicate any endpoint specific metadata that might be needed by clients interacting with this service. For example, the WSDL MAY have policy assertions that indicate a particular security mechanism used to protect the feature's operations supported by this endpoint. When a Feature WSDL does not provide...

<dug> ...a concrete endpoint, the consumer MUST use the concrete aspects of the endpoint's WSDL.

Bob: Agreed

<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Nov/0037.html

<Bob> RESOLUTION: Issue-7912 resolved with http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Nov/0037.html

Issue-8031

Katy: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8031

Asir: there are no root semantics - issue-8031

Dug: Multiple WSDL docs - example Katy has provided - we need some way which WSDL is the application

<Zakim> asir, you wanted to answer Doug's q

<Zakim> asir, you wanted to answer Katy's point

<dug> could have multiple roots

<dug> there doesn't need to be just one.

<asir> we established that root, starting point, first WSDL, real WSDL ... are not part of the use case.

<asir> So, I am a bit confused

<Katy> I need to go now - enjoy!

<Bob> bye, see you tomorrow

<asir> Here is my understanding of the use case ...

<asir> A mechanism to distinguish business services from non-business services

<asir> among metadata units in Web Services metadata (aka /mex:Metadata)

<li> if A imports C and B imports C, but you get [A,B,C] back, what are the roots?

<gpilz> but Feature WSDLs aren't imported

<dug> I want a ?wsdl flag ;-)

<gpilz> that's what makes them "Feature WSDLs"

<asir> These languages are declarative, imposes no particular processing order

<Bob> we resume

<trutt> as part of definition of wsdl dialect in mex spec, we define an optional boolean attribute, called @isImplicit, which if present with value true indicates that this is feature wsdl

<Bob> scribe Martin Chapman

<Bob> scribe: Martin Chapman

<dug> implied value is 'false'

<Bob> scribenick: MartinC

Proposal from Tom on 8031 as an agreement on concept as a way forward: as part of definition of wsdl dialect in mex spec, we define an optional boolean attribute, called @isImplicit, which if present with value true indicates that this is feature wsdl

<trutt> as part of definition of wsdl dialect in mex spec, we define an optional boolean attribute, called @isImplicit, which if present with value true indicates that this is feature wsdl

<dug> implied value is 'false'

Asir: can we record the agreed use case

<trutt> this allows the mex metadata consumer to determine if a wsdl document is intended to be treated as implicit

<trutt> I.e, that it is feature wsdl

Asir: This is different from Katy's issues desctiption

Dug: ignore any semantics implied by the term root, Tom's proposal satisfies this concerns

Agreement on the use case

proposed way forward: as part of definition of wsdl dialect in mex spec, we define an optional boolean attribute, called @isImplicit, which if present with value true indicates that this is feature wsdl implied value is 'false'

AI: Dug to produce a concrete proposal for 8031, based on Tom's directional proposal

Will return to this issue tomorrow morning.

issue 8069

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8069

<dug> agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Nov/0033.html

Revised proposal in bugzilla

<Bob> proposal at http://www.w3.org/Bugs/Public/show_bug.cgi?id=8069#c2

comment #2

Agreed to resolve 8069 with proposal in comment#2

<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Nov/att-0025/wsenum-8070-8071-8072.doc

8070 8071 8072

Dug: goes over the word doc containing proposal to resolve 8070 8071 and 8072 (link above)

Section 3:

dug: confusing combinations of musts and shoulds.
... no intention to change behaviour just to clarify

<Ram> Comment 1: Suggest removing the sentence: "Once an enumeration context is invalid, consumers MUST NOT reuse it."

Ram: hard to test when something becomes invalid

dug: ok with removing if the preceeding musts are kept

<Ram> Comment #2: Replace " For all operations defined by this specification that include an enumeration context in the request message, data sources MUST generate an wsen:InvalidEnumerationContext fault if it is able to determine that the enumeration context used is invalid." with "When processing a Pull, Renew, GetStatus or Release operation, a data source MUST generate an wsen:InvalidEnumerationContext fault if the data source determines that the enumeration cont

<Ram> Replacement text for comment #2: "When processing a Pull, Renew, GetStatus or Release operation, a data source MUST generate an wsen:InvalidEnumerationContext fault if the data source determines that the enumeration context supplied by the consumer in the request was already invalid and the data source is unwilling to perform the requested operation with the specified enumeration context."

<dug> "When processing a Pull, Renew, GetStatus or Release operation, a data source MUST generate an wsen:InvalidEnumerationContext fault if it determines that the enumeration context supplied by the consumer in the request is invalid."

Agreed to text above

<Ram> Comment #3: Rewrite the sentence: "That is, the enumeration has an indefinite lifetime. It will terminate when the end of the enumeration is reached, or if the consumer sends a Release request, or by the data source at any time for reasons such as connection termination, resource constraints, or system shut-down."

<dug> "If this element does not appear, then the enumeration will not expire. That is, the enumeration has an indefinite lifetime or until the enumeration context becomes invalid. "

<dug> If this element does not appear, then the enumeration will not expire. That is, the enumeration's lifetime extends until the enumeration context become invalid.

Observed that there is a confusion between enumerations and enumeration contexts, so Dug will rethink overnight.

Joint session with XML Security WG

xmlsec joint meeting

ping

<Yves> pong

8075

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8075

dug goes over his proposal in bugzilla

Agreed w/o to resolve 8075 with the proposal in bugzilla

8076

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8076

Asir goes over his proposal in bugzilla

Martin: is PT0S defined

Asir: yes in schema but means zero not infinite

Dug: some people like the ability to be explicit so removing PT0S will not allow this.

Martin: suggests not to do a replace but to add the last sentence

Asir: this new sentence needs to go before the note

this also needs be applied to subscriptionmanager/maxexpires

In four places: /wsenp:Enumeration/wsenp:MaxExpires, /wsenp:Enumeration/wsenp:MaxTime, /wsevp:EventSource/wsevp:MaxExpires, /wsevp/SubcrptiionManager:MaxExpires

add the sentence "The implied default is indefinite (no expiry)." before the text "Note: a value of "PT0S" indicates that this endpoint supports enumerations with an infinite lifetime."

Agreed w/o to resolve 8076 with proposal above

6436

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6436

<Ram> http://www.w3.org/Bugs/Public/attachment.cgi?id=779

Ram goes over his proposal for the enumeration state table

dug: would like to see an END column(state) as it is different from none

Gil: some failures/faults should go to the end state

Dug: Gils proposal drew this differently and was more intuitive to this representation

Discussion of Gil's representation vs Ram's

<dug> Gil's enum: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/att-0031/Enumeration-State-Tables-v1.doc

Bob: need an enumeration factory state table

If you have such a table you dont need the start state, but you probably need an end state

Bob: general perference for Gil's representation as they better capture the transitions

Ram: happy to re-do the table in this style.

Bob: sometimes tables like sthis can be optiimised but best to do this after a full table is finished

General agreement that the state table will be but into appendix, editors discretion. also need some intro text and text to describe how to read the tables.

Discussion on whether the appendix will be normative or not, and the precedence order of these over spec text/schema

<Bob> act tru

Martin: Lets focus on getting the table's correct, and worry about status and order later

Decision to add a a new table for enumeration factory

<scribe> ACTION: Gil to produce new enumeration state tables [recorded in http://www.w3.org/2009/11/05-ws-ra-minutes.html#action02]

<trackbot> Sorry, couldn't find user - Gil

into text to the tables to be part of this action.

Bob: proposes that these should be Informative

Dug: what is the point if its not part of the precedence order

Tom: its more about spec hygene, so dont even have to be in the spec

Agreed that they should be non-normative, provided we pay attention and ensure the spec text covers all the cases described in the tables.

<dug> 8070: latest proposal: http://www.w3.org/Bugs/Public/attachment.cgi?id=780&action=edit

back to 8070

http://www.w3.org/Bugs/Public/attachment.cgi?id=7808

<Bob> http://www.w3.org/Bugs/Public/attachment.cgi?id=780

in enumerateresponse/grantedexpires, 3rd paragraph

Agreed 3rd paragraph is accurate and should stay

in section , Enumeration messages

<scribe> New set of bullets about enumeration context, agreed these are ok

Pullresponse/Endofsequence, new text

Agreed the next text is ok

Section 4.8 timedoutfault new text, agreed text is ok

enumerateResponse/enumerationcontext added two words

gil, in same paragraph remove the word context from 2nd sentence

Agreed to new words and removal of "context" from second para

3.4 GetStatus

4 words deleted - agreed these are ok

<dug> http://www.w3.org/Bugs/Public/attachment.cgi?id=781

Agreed w/o to resolve 8070 8071 and 8072 with the proposal at http://www.w3.org/Bugs/Public/attachment.cgi?id=781

meeting recessed

- DRAFT -

Web Services Resource Access Working Group Teleconference

05 Nov 2009

Attendees

Contents