See also: IRC log
<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
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
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.
<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: 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
ping
<Yves> pong
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
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
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
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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/patiece/patience/ Succeeded: s/it/the consumer/ Succeeded: s/can/to/ Succeeded: s/preced/preceed/ Succeeded: s/proposal/proposal above/ Succeeded: s/gave/have/ Found Scribe: Sreed Inferring ScribeNick: Sreed Found Scribe: Martin Chapman Found ScribeNick: MartinC Scribes: Sreed, Martin Chapman ScribeNicks: MartinC, Sreed WARNING: Replacing list of attendees. Old list: apis-db-stuff +1.571.262.aaaa asoldano +0196270aabb li +1.571.262.aacc +1.571.262.aadd New list: li apis-db-stuff Default Present: li, apis-db-stuff Present: li apis-db-stuff WARNING: Fewer than 3 people found for Present list! Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Nov/0033.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 05 Nov 2009 Guessing minutes URL: http://www.w3.org/2009/11/05-ws-ra-minutes.html People with action items: gil WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]