See also: IRC log
<trackbot> Date: 30 September 2009
<Bob> scribe: Paul Fremantle
<Bob> scribenick: paul
<scribe> chair: Bob Freund
bob: takes attendance
... All issues are fair game for discussion. The agenda is my
attempt to group them.
ram: can we group the policy issues
bob: agenda is acceptable
RESOLUTION: minutes of 2009-09-22 are approved.
<asoldano> (I get a lot of noise, might loose something in the conversation)
jeff: Martin is going to be added as a member
Katy: Paul is offering a tour of the
Bell Tower in Winchester Cathedral. Don't be late. 6.55pm. The big
entrance.
... Meal booked at the Old Vine around 8ish
Bob: next item - November F2F. Please
register.
... will we need a January F2F.
Dave: January is close and we are far enough from finishing.
bob: 2 people think Colombo is a good
place
... 7 people for the Bay area
... 4 for Japan
... proposed dates Tues 26th-Thurs 28th Jan 2010
... tentatively hosted by Fujitsu in Sunnyvale/Santa Clara
... sent drafts to potential reviewers
... cancel next Tuesday's telecon. No objections. Tues 6th October
cancelled
trackbot-ng, comment action-100 in process
<trackbot> ACTION-100 Automate cross-links among WS-RA specs notes added
close action-102
<trackbot> ACTION-102 Create new proposal for 7553 closed
close action-103
<trackbot> ACTION-103 Create proposal for 7554 that considers 7553 closed
trackbot-ng, comment action-104 still working
<trackbot> ACTION-104 Produce proposal for 7589 notes added
trackbot-ng, comment action-88 Dug still in discussions with Ram
<trackbot> ACTION-88 Come back witth a new proposal for 6724 before next meeting. notes added
trackbot-ng, comment action-85 Waiting until policy is done
<trackbot> ACTION-85 7068 addressed by F2F notes added
trackbot-ng, comment action-36 Deferring. Needs to be done before CR
<trackbot> ACTION-36 Write a draft proposal for management of migration notes. notes added
<Bob> Issue-7716 Clairfy Enumerate operation http://www.w3.org/Bugs/Public/show_bug.cgi?id=7716
Asir: explains the issue (reads from description)
bob: no objection to opening issue.
Issue is opened. Note there exists a proposal
... Clarification seems straightforward
Dug: why wasn't it like this to start with.
Asir: Oversight (Oops)
Bob: any objection to accepting this
proposal as the resolution
... No objections. Resolved and accepted
<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7728
RESOLUTION: Issue-7716
resolved with proposal as noted in bugzilla
... No objection to opening new issue-7728
issue is open
<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7731
RESOLUTION: no objection to opening 7731
<Bob> http://www.w3.org/2002/ws/ra/edcopies/wsfrag.html
bob: accept this specification as the
resolution of the 7088.
... issues can still be opened against this spec
... remove section 'Open Questions and Actions' and then raise
these as new issues against this spec
... any objection to doing these both?
asir: why bold?
bob: seems strange to bold stuff,
when this is a new spec
... proposal to move forward.
... no objection
RESOLUTION: issue-7088. Add new spec without section D. Raise all section D items as new issues against the spec.
Dug: yes we can update the WSDL and XSD for WS-Fragment in the next couple of days
<scribe> ACTION: Dug to Update WSDL and XSD for WS-Fragment due 2nd October 2009 [recorded in http://www.w3.org/2009/09/30-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-107 - Update WSDL and XSD for WS-Fragment due 2nd October 2009 [on Doug Davis - due 2009-10-07].
bob: Aim for FPWD of WS-Fragment by
end of week
... assumption is that with WS-Fragment RT will go away. Any
objection to ceasing work on RT
... none
RESOLUTION: close RT and remove issues (mothball spec)
bob: ask permission of the group for Bob to work with Yves to identify the right approach for mothballing RT
Dave: See if they have a proper way of doing this
RESOLUTION: Bob to work with Yves to determine propoer method to mothball the RT specification
<Bob> -Issue-6422 RT - Introduces An Ad Hoc Boxcarring Mechanism http://www.w3.org/Bugs/Public/show_bug.cgi?id=6422
<Bob> -Issue-6549 RT - Create focused on resource fragments http://www.w3.org/Bugs/Public/show_bug.cgi?id=6549
<Bob> -Issue-6550 RT - Support for XSLT and XQuery in PUT http://www.w3.org/Bugs/Public/show_bug.cgi?id=6550
<Bob> -Issue-6552 RT - Lifecycle metadata for Create http://www.w3.org/Bugs/Public/show_bug.cgi?id=6552
<Bob> -Issue-6576 RT - No Fault Defined for Mismatch between ResourceTransfer header and message body http://www.w3.org/Bugs/Public/show_bug.cgi?id=6576
<Bob> -Issue-6578 RT - SideEffects applies to other faults http://www.w3.org/Bugs/Public/show_bug.cgi?id=6578
<Bob> -Issue-6579 RT - Bad fragment values with Create http://www.w3.org/Bugs/Public/show_bug.cgi?id=6579
<Bob> -Issue-6603 RT - Inconsistencies in CreateResponse message http://www.w3.org/Bugs/Public/show_bug.cgi?id=6603
<Bob> -Issue-6634 RT - Document algorithm for modify http://www.w3.org/Bugs/Public/show_bug.cgi?id=6634
<Bob> -Issue-6636 RT - Add example of resource after the create http://www.w3.org/Bugs/Public/show_bug.cgi?id=6636
<Bob> -Issue-6691 WS-T/RT - Reconcile faults http://www.w3.org/Bugs/Public/show_bug.cgi?id=6691
Wu: should open any against Fragment spec.
Bob: proposal to close with no action all the above listed issues against RT
Asir: believes these issues will not re-open against Frag
Bob: any objection to close these 11 issues?
Asir: Issue-6691?
Katy: Will look at these and raise issue if needed
Bob: Any objection to closing?
RESOLUTION: All 11 issues are closed with no action.
Bob: re-target 6407 to Frag?
RESOLUTION: retarget 6407 to Frag
<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/att-0090/6403-proposal.doc
katy: nested enumerate is no longer required. Simplified proposal.
Dave: proposal is to remove last sentence on the first para. The sentence doesn't help, just confuses.
<dug> text dave wants to remove: The wsenp:Enumeration policy assertion specifies a concrete behaviour whereas the wsdl:portType or wsdl20:interface is an abstract construct.
bob: no objection to remove: "The wsenp:Enumeration policy assertion specifies a concrete behaviour whereas the wsdl:portType or wsdl20:interface is an abstract construct."
<Katy> <wsp:Policy>
<Katy> <wsenp:EnumerateRequired wsp:Optional=true.../> ?
<Katy> </wsp:Policy>
Bob: no objection to remove ' <wsenp:EnumerateRequired wsp:Optional=true.../>'
Dug: doing real-time edits.
Dave: do we need to edit the first part of the para?
Dug: nope
Asir: need to remove 'with nested policy assertions' as well
dug: Also further cascaded edits
Asir: need a schema
Martin: general question. When you get to the schemas do they need to list valid values? e.g. FilterDialect.
Dug: in other specs (e.g. eventing). Schema does specify default value.
Asir: references within the spec?
... resolution to 7716 obviates need for nested policy
assertions
bob: first editorial note can be
removed
... second editorial note?
Asir: suggestion - leave this note until we have resolved other related issues
Dug: uncomfortable leaving the notes
Asir: common approach in W3C
<Yves> ednotes can stay until REC
Dug: prefer an issue.
<Yves> and even in some RECs you can find ednotes
gpilz: Filter dialect is a parameter not a nested policy assertion. If I'm a consumer only supporting one dialect. I'd like to use a policy assertion matching algorithm. As a parameter, I need to understand the details.
Katy: If you put as a nested assertion. It would need an attribute.
gpilz: What about using a policy assertion in the namespace of the filter dialect. No attributes
katy: problem: Couldn't establish list of filter dialects
dug: every solution has a problem. Stealing someone elses namespace
gpilz: don't have to use xpath's namespace. We can create our own namespaces for dialects.
dug: that is true.
... requires that anyone defining that ns doesn't use the name
filter dialect
gpilz: would like to see nested
policy assertions for Filter Dialects.
... sees this as policy matching
... don't have to write code. Just construct the policy and
match
dave: clarifies Gil's discussion
Asir: if you want to do policy matching. Nested policy assertion with a qname that matches the dialect.
GPilz: the qname MUST be
<our-xpath-ns:FilterDialect>
... re-iterates that we shouldn't be using XPath's namespace.
Asir: come up with our own qname
gpilz: Need to define a new filter
dialect, then you either need to create a URI or a QName
... if you create a new dialect, here is a template assertion
dug: answer why it needs to be a template. imagine a generic pub/sub client. Need to drop down potential dialects. Look for assertions with the tag "FilterDialect", then populate list with URIs
<dug> <urn:foo wsenp:filterDialect="xs:anyURI"/>
asir: proposes a joint solution
dug: do I still need to know urn:foo
katy: Paul Nolan had a suggestion to combine these message assertions
<asir2> i would like an opp to respond to Katy
gpilz: I want to use policy matching
to solve this problem
... If I don't dictate the template. Now I need to know the qname
and the assertion
... If you give a template, then its simpler/more
straightforward.
asir: respond to Katy. In the urn:foo example. In that case its just additional information. The real semantics is in urn:foo. Always pick up the addition semantics.
<dug> <foo:FilterDialect xmlns:foo="...xpath2.0"/> is gil's
paul: prefers the status quo, then asirs
dug: can we mandate that you must provide that attribute.
gpilz: we must
Bob: do we leave this in?
Dave: prefer to raise this note as an issue
<scribe> ACTION: Asir to raise second and third editorial note as new issue and they will be deleted. [recorded in http://www.w3.org/2009/09/30-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-108 - Raise second and third editorial note as new issue and they will be deleted. [on Asir Vedamuthu - due 2009-10-07].
gpilz: happy to accept this and raise a new issue
bob: accepting this proposal will not stop Gil raising issues
<gpilz> ACTION: gpilz to raise issue about support for "generic enumeration clients" [recorded in http://www.w3.org/2009/09/30-ws-ra-minutes.html#action03]
<trackbot> Created ACTION-109 - Raise issue about support for "generic enumeration clients" [on Gilbert Pilz - due 2009-10-07].
dug: produces newly updated proposal out of hat
<dug> word doc: http://www.w3.org/Bugs/Public/attachment.cgi?id=747
Dug: produces edits
RESOLUTION: accept Dug's edited proposal: http://www.w3.org/Bugs/Public/attachment.cgi?id=749
dug: is the group ok with the editors applying this accepted policy doc as a template for the other policy docs
RESOLUTION: yes the editors can go ahead with using this doc as a template for other specs
Bob: take a look at Eventing Policy specs
<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0116.html
katy: introduces proposal
Wu: proposes change to default ns shortname
katy: there are mistakes in this.
FormatName should be URI not duration
... also - s/nested assertions/parameters/
Asir: drop line saying "If DateTime..... MUST include this assertion"
Dug: should we drop editorial note and raise issue?
Bob: editorial note is already covered by Asirs new issue
Asir: same issues apply to the SubsMgr policy too
Dug produces attachment
<Bob> http://www.w3.org/Bugs/Public/attachment.cgi?id=750
<Bob> http://www.w3.org/Bugs/Public/attachment.cgi?id=751
<Bob> http://www.w3.org/Bugs/Public/attachment.cgi?id=752
wu: needs more time to review
katy: could we accept now and then raise issues
bob: wants to timebox to a day
... revisit tomorrow.
martin: in the format name, it doesn't offer the potential values.
dug: the PT0S is a special value, hence in the policy. There is an issue to discuss this in the spec too
Wu: similar discussion around delivery push
Bob: should we do push first?
martin: more concerned about overall consistency between policy and protocol
bob: revisit tomorrow
dug: explains proposal
katy: the ? should be a *
group: edits document
<dug> link to proposal: http://www.w3.org/Bugs/Public/attachment.cgi?id=753
<Bob> ok
<scribe> ACTION: paul to raise new issue - how does a resource factory say 'i will always create resources with a consistent policy and what is that policy' [recorded in http://www.w3.org/2009/09/30-ws-ra-minutes.html#action04]
<trackbot> Sorry, amibiguous username (more than one match) - paul
<trackbot> Try using a different identifier, such as family name or username (eg. pnolan, pfremant2)
<scribe> ACTION: pfremant2 to raise new issue - how does a resource factory say 'i will always create resources with a consistent policy and what is that policy' [recorded in http://www.w3.org/2009/09/30-ws-ra-minutes.html#action05]
<trackbot> Created ACTION-110 - Raise new issue - how does a resource factory say 'i will always create resources with a consistent policy and what is that policy' [on Paul Fremantle - due 2009-10-07].
<dug> http://www.w3.org/Bugs/Public/attachment.cgi?id=754
group: edits document
<dug> Proposed new text: When present, this parameter indicates that attempts to change the representation that are read-only will generate a wst:PutDenied fault. If this parameter is not present, attempts to modify read-only portions of the resource representation will be ignored.
<dug> one more try: When present, this parameter indicates that attempts to change portions of the representation that are read-only will generate a wst:PutDenied fault. If this parameter is not present, attempts to modify read-only portions of the resource representation will be ignored.
<dug> just for wu: When present, this parameter indicates that attempts to change portions of the representation that are read-only will generate a wst:PutDenied fault. If this parameter is not present, attempts to modify read-only portions of the resource representation will be ignored.
<dug> with an edit from Wu: When present, this parameter indicates that attempts to change portions of the representation that are read-only will generate a wst:PutDenied fault. If this parameter is not present, attempts to modify read-only portions of the resource representation will be ignored without any fault being generated.
<Bob> scribe: Martin Chapman
<dug> latest: http://www.w3.org/Bugs/Public/attachment.cgi?id=755
<Bob> scribenick: MartinC
<dug> final: http://www.w3.org/Bugs/Public/attachment.cgi?id=756&action=edit
<dug> oops http://www.w3.org/Bugs/Public/attachment.cgi?id=756
A few editorial changes in attachment 756
Asir: what is the relation between this and 6721
Katy: will make a proposal for 6721
Asir: thinks 6721 is possibly a close no action
Bob: consider 6721 separately as a different issue
No objection to resolving 7731 with comment #5 (www.w3.org/Bugs/Public/attachment.cgi?id=756)
<dug> mex latest: http://www.w3.org/Bugs/Public/attachment.cgi?id=757
looking at the attachment http://www.w3.org/Bugs/Public/attachment.cgi?id=757
Wu: should we remove the note
Dug: it is there as a reminder
<dug> doc: http://www.w3.org/Bugs/Public/attachment.cgi?id=758
RESOLUTION: No objection to resolving 6406 with comment #2: http://www.w3.org/Bugs/Public/attachment.cgi?id=758
Ashok introduces his issue
Ashok: point 1 is what needs to be addressed, propbably 2. has been covered
<Katy> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6463
Katy: is this related to 6463?
Ashok: maybe, didn't look at it.
Asir: dupl?
Ashok: need to look at whether 6463 deals with point 1
Mark as dependant on 6463, and will discuss in that order
Katy: goes over the issue
Paul: why are operations implicit?
Katy: this is policy applied to mex
Dug: we agreed that the operation are implicit incl on transfer so might have to re-open ssue 6694
Katy: designed not to be complicated if you didn't want to use it, hence the use of policy attachements
<dug> from transfer: An endpoint MAY indicate that it supports WS-Transfer, or its features, by including the WS-Transfer Policy assertion(s) within its WSDL. By doing so the endpoint is indicating that the corresponding WS-Transfer operations are supported by that endpoint even though they do not explicitly appear in its WSDL.
Paul: is there a way we can point to the wsdl operation?
Like an implicit import
Katy: policy attachment is a way to
do exactly this
... provides more flexibility this way
... especially if different policies in different directions
Asir: What is the PolicyAttachement?
An assertion?
... <wsp:PolicyAttachement>
... how does this fit in the policy model if its a parameter
... what is the subject of the uri
Katy: what we define the uri to mean,
in this case a uri expression of a subject
... applies to the implicit operation/message
Asir: so there are a range of subjects (input/output/faults)
need a predefined way to identify the subjects
Paul: want to attach a policy to the imported wsdl
Gil: should we take it outside Enumeration?
Katy: its related to a specific endpoint
Paul: two sub issues: where does the policy live? and is there a standard way to refer to the subjects?
Katy: we need this for the getmetadata
Paul: seems complicated since we have hidden the operations
Asir: Agrees with Paul, attach a
policy expression to wsdl
... attachment is not a policy assertion
Gil: goes over the use-case for this
feature
... will be strange behaviour for current wsdl tools
... if explicit tools will generate stubs
Katy: its a difficult problem and best for the spec to solve
Paul: will be hard to configure current stacks to support this without cut/paste implicit operations into the wsdl
Dug: The infrastructure supports these operations so they don't need to be made explicit
Martin: is this spec the place to define a uri mechanism to identify wsdl parts
Katy: we need something like this for our specs
Paul: implicit or not, a client just
calls like any other wsdl operation, and policy should be attached
as such
... why should you hack the stack to do this
<dug> its akin to saying "the only way RM would work is if you implement RM" - its circular
Gil: can all be hidden by an api
... different levels of users want different capabilities
... good reasons these are implcit
Dug: only user defined operations should be exposed to the user
<dug> mex.getMetadata(".../TransferWSDL")
Dug: should we standardise the way to expose the wsdl
Martin: client side view should be the same
Dave: suggestion to embed the implicit wsdl in the meta-data of the epr (which can be done now)
Katy: will go away and re-think
Asir: doesn't understand the proposal, so re-work would be nice
Bob: asks which direction we should look for a solution
<dug> mex.getMetadata(".../TransferWSDL")
<dug> mex.getMetadata(".../RMWSDL")
<dug> define a new mex Dialect to retrieve the WSRA WSDL docs - these WSDL docs can be annotated with policy as needed
<scribe> ACTION: IBM to produce an updated proposal for 6721 [recorded in http://www.w3.org/2009/09/30-ws-ra-minutes.html#action06]
<trackbot> Sorry, couldn't find user - IBM
Katy: can we postpone until the previous issue (6721) is progressed
Bob: Start with charter which says:
<DaveS> Current Charter Says: "The Web Services Resource Access Working Group will define the specifics of their exit criteria before Last Call. The Working Group is expected to demonstrate at least two interoperable implementations of each deliverable during the Call for Implementations step of the set of features not marked as "at risk" for each Recommendation specification."
Bob suggests: this must include ALL mandatory and optional features
To be considered a valid implementation it must do the Mandatory and may do the Optional, but to pass exit there must be at least two of each optional feature
Dug: whats the relationship between end-points and impls?
Martin: should the impls come from different companies
Bob: they must be from independent code bases.
Jeff: different companies provide better coverage of spec debugging
Martin: academic discusion if we have two imple from different companies
Bob: the W3C mentatlity is to
interpret and test the spec, so if can prove different people then
its ok
... Minimum goal is two impls from two diff companies
Doug: but surely two independent code bases is ok
Jeff: an impl should do all optional features as well, since typically optional features rely on the others
Bob: may be able to define sensible pairings
Jeff: transitive is ok, but may miss
some combinations
... therefore easier to say do all optionals
<paul> folks I have to go but its been fun.
<paul> I hope to see you on Friday
Bob: pairwsie testing has been acceptable in w3c
Li: compliance is defined in each
spec and should be obvious from the section
... if two teams never talk to each other then shouldnt matter if
in same company
Martin: is conformance related to exit criteria
Bob/Jeff: seems like a necessary condition
corollary is that this test the conformance criteria
Jeff: not convinced the combinations will be covered, and suggest that at least two impls of all features
Bob: cant go bellow w3c process requirements, but can go beyond it, which is what we are talking about
Summary proposal is:
two interop impls where
1) all mandatory features implemented by all impls
2) Each optional feature must be represented in at least two interoperable impls
3) Any impl used to test an optional feature must implement all mandatory features
4) Two interop impls means two different code bases from two different companies
5) All implmentation used for testing must be conformant to the specification as defined by the spec
<asir2> This is a proposal!
<asir2> We would like to check what 5) entails ...
Bob: first proposal on exit criteria, please think about and raise concerns
We need to agree the exit criteria before last call
<asir2> Two independent implementations are sufficient
Asir: whats the rationale for two different companies
Jeff: to minimise group thinking, you get better independent interpretations of the spec
Ram: we should define a minimum bar for success, but aim for more
<Yves> what matters is two independant codebases, the fact that a company may hold two different codebases after a merger, or the fact that two companies are using the same codebase proves that "company" is not a good metric
<asir2> Two interoperable implementations are sufficient
Wu: two independent is fine, the group can judge how independent
Gil: mergers are complicated so why consider here
<Yves> independant _codebase_
<Yves> the company issue is irrelevant there (just loosely coupled)
<Yves> the goal of interop is that the specification can be implemented by different people with the same understanding
<Wu> Two independent implementations will be sufficient. This WG makes judgement on the validity of two implementation. We should tie it to merger, etc.
Dug: if can prove two indendent groups of people test the spec isn't that ok
<Wu> replacement /should tie it/should not tie it/
<asir2> I hear a lot of pushback on ... 2 independent companies
<scribe> ACTION: Freund propose exit criteria on the email list [recorded in http://www.w3.org/2009/09/30-ws-ra-minutes.html#action07]
<trackbot> Created ACTION-111 - Propose exit criteria on the email list [on Robert Freund - due 2009-10-07].
David: this a technical spec quality
issues and we exit when we are happy the spec is suitably
tested
... everything else is market consideration and out of scope
Gil: goes over the issues wrt
expiration
... similiar issue with ws-eventing on a subscription manager
... two ways to resolve
... 1) abide what the client want or fault, or
... 2) remove the illusion of control from the consumer
gil favours removing expiration
Dug: option 2 forces a renew which
maybe too costly
... can live with option 1
... doesn't understand the pushback on option 1
<dug> 195.212.29.83
<dug> yves - that was my IP
Martin: favorurs option 1
Wu: Subscriber can always reject the
request
... consumer may not have an idea of the capability of the
subscripion manager
Bob: typically if it cant meet the requirement it doesnt give another time, it rejects
Wu: stay with the current spec as it
gives the desired behaviour
... current spec says if the expiration cant be met the
subscription is still created
Ram: we all have different use
cases
... trying to find a solution for all
... Dug's outline proposal seemed reasonable
Dug:
<Wu> Unless the subscribers with the counter offer, otherwsie the subscriber unsubscribes and terminates.
Dug: its not an offer you get back
from the source, its what was given, so its not really a
negotiation and a fault would be better
... cWhy is the expires property different from the other like e.g
filterdialect wih is ok to fault
Gil: Doesn't see a lot of value in
hints, you either care or don't care
... still have to code as if have no control
... what does "close" or "best efort" mean
Martin: if we add a "variance" property to option one which indicates a tolerance level to option 1 will that cover most use cases?
Li: wants to accomdate both options
Bob: can accomodate all use casess with two values one of which is optional
Wu: differnec with filterdialiect is
that subscription can not work if dialect is not supported
... how about an extra parameter called "exact" which will fault if
the exact expriation cant be supported
Doug: if its required then can go for that
<Bob> ok, we are wrapping up
Agreed that propsal 2) removal is a no go
<scribe> ACTION: Gil write a new proposal for 7587 and 7478 and bounce to the group on email before Friday, to discuss on Friday [recorded in http://www.w3.org/2009/09/30-ws-ra-minutes.html#action08]
<trackbot> Sorry, couldn't find user - Gil
<Bob> on ms, gil, Li
Bob: thanks the organisers for todays meeting
Meeting is recesssed
<Bob> thanks Martin and Paul for scribing