W3C

Web Services Resource Access Working Group Teleconference

05 Nov 2009

Agenda

See also: IRC log

Attendees

Present
Alessio Soldano, Red Hat
Ashok Malhotra, Oracle Corp.
Asir Vedamuthu, Microsoft Corp.
Bob Freund, Hitachi, Ltd.
Doug Davis, IBM
Fred Maciel, Hitachi, Ltd.
Gilbert Pilz, Oracle Corp.
Jeff Mischkinsky, Oracle Corp.
Katy Warr, IBM
Li Li, Avaya Communications
Martin Chapman, Oracle Corp.
Ram Jeyaraman, Microsoft Corp.
Sreedhara Narayanaswamy, CA
Tom Rutt, Fujitsu, Ltd.
Vikas Varma, Software AG
Wu Chou, Avaya Communications
Yves Lafon, W3C/ERCIM
Absent
Bob Natale, MITRE Corp.
David Snelling, Fujitsu, Ltd.
Mark Little, Red Hat
Orit Levin, Microsoft Corp.
Paul Fremantle, WSO2
Paul Nolan, IBM
Prasad Yendluri, Software AG
Regrets
Chair
Bob Freund, Hitachi, Ltd.
Scribe
Sreed Narayanaswamy, Martin Chapman

Contents


<trackbot> Date: 05 November 2009

<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

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 April 1st - Oracle is going to check if they can host the meeting

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

<scribe> ACTION: Gil to check the possibility 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

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 midnight 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

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

RESOLUTION: Agreed to resolve 8069 with proposal in comment#2

Issues-8070 8071 8072

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

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

<Bob> scribenick: G-Edgar

bob: A need to define an xpath subset
... we need different profiles for different purposes

there other xpath subsets for other purposes

<fjh> pratik notes having multiple subsets might make implementation difficult

for streaming we want xml 2.0 to have good performance for streaming

Pratik: when we are streaming we should not have to make more than one pass

there is not a since element, but it could be a large part of the document

<fjh> xml signature 2.0 xpath subset at http://www.w3.org/TR/2009/WD-xmldsig-core2-20091022/#spec-xpath-subset

<fjh> ws-fragment editors draft http://www.w3.org/2002/ws/ra/edcopies/wsfrag.html

<fjh> focus on ws-fragment simplification of selection

Bob: there is a need to simplify selection of a subset

transfer by default transfers everything

Pratik: we are trying to make it work on limited devices.

Frederick: to start with questions, there might be obvious things

Pratik: can we have a similar subset?

Frederick: there are multiple paths and potential for confusion.
... we can continue to use what we have, we can (or might be able to) improve performance,
... we have the WS-* stack

brian: there are three ways to sign: you can sight the entire document, you can imbed the signate, or you can do detached signatures
... you can do the whole document, or you can do a portion of the document

Frederick: you use an enveloped signature, selecting portions of the message to sign
... one goal of our work is performance

Doug: look at section 4.4.3.5
... how to look at that table

Pratik: there is a need to selectively sign "ceiling" and "floor"
... there is a need for a little more logic

Doug: can we use a layering approach?

Frederick: can we use XPath transfer?

Pratik: can we have a seperate document of an XPath subset?

Frederick: we can have a simgle document specifying level one and level two
... this could address both transfer and signature
... there is a lot of overlap

<pdatta> http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0032.html

PRatik: streaming pasers should break up what is received

Pratic: we do not have a parse function

Pratik: we do not have a relative XPath
... everything is relative to the root

Frederick: we will have a base that is common to everything, and then portions for signature and streaming

Doug: if one is not a superset of everything, then we need to look carefullly and make sure there is not an issue

Pratik: if there is more than one subset we need to examine to determine if one has everything of the other subset

Frederick: we need to have a core and additinal elements that will make each subset

Is there an existing subset?

Bob: transfer and fragment are seperate secs

Frederick: to reference the fragment document
... we would have additional constraints, Fragment can go ahead as it is, we can referenace it normatively
... we would have a small document to define signature needs for this

DOug: take a look of Fragment, it is more than XPath

Frederick: we should review the WS-Fragment document

Brian: to use a small XPath document for our needs

Asir: XMLScema and XMLQuery have subsets now

Brian: there is no mandatory subset. There is no guaranteed interop

Bran: we do not have a relative XPath

Bob / Asir : we need to establish context

Doug: to start with a slash

Bob: you can not go up above the body
... streaming is an xpath processor issue

PRatik: you are not combining all the chunks

Frederick: should Fragment have an XPath doc?

Doug: to pull in QName,
... we need to work together to have a central document

Bob: are we OK with the change? or potential changes?
... he is hoping for a spring last call for a candidate recommendation

Frederick: this is a action on the Fragment working group

Bob: a first step to respond to the analysis, then to have a review and reconsiliation of they group and our needs

Freederick: this is a good idea to have a joint meeting and come to a conclusion.

<Bob> scribenick: MartinC

WS-RA resumes

8075

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

dug goes over his proposal in bugzilla

RESOLUTION: 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."

RESOLUTION: 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.

back to 8070, 8071, 8072

<Bob> proposal at 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

RESOLUTION: 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

Summary of Action Items

[NEW] ACTION: Gil to check the possibility 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]
[NEW] ACTION: Gil to produce new enumeration state tables [recorded in http://www.w3.org/2009/11/05-ws-ra-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/11/19 16:32:43 $