See also: IRC log
<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 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
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
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
RESOLUTION: Agreed to resolve 8069 with proposal in comment#2
<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.
<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
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
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
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.
<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