See also: IRC log
<trackbot> Date: 12 May 2009
<Bob> scribe: Miar Little
<Bob> scribe: Mark Little
<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/
<marklittle> chair: any objections to approval minutes from May 5th? None. Accepted.
<marklittle> chair: has there been enough time to look at incorporated issues? Some indication that more time needed. One more week extension.
<marklittle> chair asks for status update
<marklittle> gpilz making progress. couple of issues remaining but no main problems or disagreements at this stage.
<marklittle> chair what is expected completion date?
<marklittle> gpilz what's expected?
<marklittle> chair closure of issue 6401.
<asir> closure?
<marklittle> chair resolution of 6401 direction would be sufficient so we could then work on text. Though text would be better. What is problem?
<marklittle> chair why not just forward proposal for discussion?
<marklittle> chair will put this back on the agenda for next week. Would like to see something to discuss before then if possible.
<marklittle> Wu posted already.
<marklittle> chair if version posted by Wu is good enough, let's start discussions around it. Move commentary to public list.
<marklittle> chair none currently.
<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6860
<marklittle> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6860
<marklittle> gpilz discusses issue and asks if there are any concerns over removing wsen:EnumerationContext?
<marklittle> chair everyone ok with proposal? no objections.
<marklittle> resolution: 6860 resolved
<marklittle> s/resolved/resolved as per bugzilla issue/p
<marklittle> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6696
<gpilz> s/and an problem is detected/and a problem is detected/
<marklittle> Geoff fine in general, but "If this check is performed and a problem is detected then the event source MUST generate [fault]". Only place in spec with MUST other than MAY. Why?
<marklittle> dug generating is different from transmitting.
<marklittle> Geoff should be consistent though. Either all MUST or all MAY. If former then we should raise another issue to make them all MUST.
<marklittle> dug agrees.
<marklittle> +1
<marklittle> li does MAY mean if something else went wrong you can generate this one or something else? Case of multiple errors, where this may not be the first one that you generate.
<marklittle> dug not sure, but he suspects the spec is silent on the case of multiple faults. Implementation choice. MUST or MAY wouldn't change that aspect of the spec.
<marklittle> Geoff it says it "SHOULD have some cursory validity" But maybe MAY?
<marklittle> dug prefers SHOULD as it's a recommendation. Pious advice is better.
<marklittle> DaveS the fault raising is InvalidEPR. Is there anything people may check that could make this a confusing fault? Such that if it fails it could be a valid EPR but could get back an InvalidEPR fault because of this.
<marklittle> dug UnsupportedEPR?
<marklittle> DaveS limit it to checking semantic validity of EPR then it's accurate as InvalidEPR.
<marklittle> chair change InvalidEPR to UnusableEPR?
<gpilz> For example, an unsupported transport specified within the wsa:Address IRI.
<marklittle> Geoff any way we can be more specific what cursory validity checking means? Seems vague.
<marklittle> dug yes, that's deliberate. Didn't want to be specific. Leave it to the implementation so they can choose what they can check.
<marklittle> dug open to stronger wording if we can agree on it.
<marklittle> Geoff would prefer some stronger wording. Just not sure what that is.
<marklittle> dug maybe a separate issue? So we can close this one?
<marklittle> Geoff yes, will create another issue later.
<marklittle> chair reviews two changes. Everyone willing to adopt?
<Bob> also change MUST/MAY
<Bob> and s/InvalidEPR/UnusableEPR
<marklittle> chair no objections.
<marklittle> resolution: adopted 6696 as per the bugzilla resolution and incorporating the 3 changes mentioned previously.
<asir> Vow!
<dug> make the same change to ws-enum too
<marklittle> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6724
<DaveS> Note: If someone wants to open up a word smithing issue wrt 6696, they need to make sure to include Enumeration as well as Eventing.
<marklittle> DaveS checks that cases where part of description can be updated and part may not be. Transfer supports this, correct?
<marklittle> dug yes
<asir> :-)
<marklittle> Geoff as usual not keen on making changes to functionality unless good reasons. Can't see good reasons with this one. Why delete current interfaces? Also general concern about moving to generalized interfaces versus specific interfaces. Can be confusing about what's happening.
<marklittle> Geoff Seems like pointless thing. Why not add it and have it in conjunction with existing interfaces?
<marklittle> Wu concerned on proposal too. Renew/getstatus well defined in eventing with well defined semantics. Shouldn't replace them. Maybe augment them instead, but definitely keep existing interfaces.
<Wu> not clear what kind of complexity that this will bring to WS-E and how interoperable.
<marklittle> DaveS if this was optional then it would be fine. Worried about supporting old and new approaches though. Is there anything different in the proposed semantics versus those that are already in the specification?
<marklittle> dug not my intent to break the semantics.
<marklittle> dug understands the arguments about generic versus specific. Thought removing old interfaces was better so that there were not multiple ways of doing the same thing. But thinks that the generic is good even if the old interfaces remain. Compromise?
<marklittle> Katy thinks it's an interesting proposal.
<marklittle> chair asks dug if this presents challenges to distributed implementations, particularly when asked "where is the state?" Could implement eventing where state is placed in to clusters. This proposal would require that representation to be mapped from wherever it is accessed. Does there need to be any kind of consistency control (transactions, locking)?
<marklittle> dug that's an implementation detail.
<marklittle> dug maybe this is a general transfer question?
<DaveS> Dave dropped briefly
<dug> LOL blame me???
<marklittle> gpilz likes proposal but not the notion of replacing the existing interfaces.
<gpilz> more accurately I don't like the idea of using WS-T Put to do things like Renew and Cancel
<marklittle> chair summarizes that people like proposal if it augments the existing rather than replaces.
<gpilz> but I think using WS-T Get to get a "more detailed version" of the subscription status is usefull
<marklittle> chair could we remove point 1 in proposal? No objections.
<dug> gil - the proposal doesn't talk about cancel. And people are not required to support Put.
<marklittle> chair ok let's remove point 1 on proposal. Anyone disagree that reading full XML of subscription is not a good idea?
<li> subscriber knows properties of subscription except the expire which may change, so getting other properties is not necessary
<li> if updating other properties is necessary, can we argment renew operation for that?
<marklittle> Geoff what's difference between this and having GetStatus being extensible so that certain event sources can return more information?
<marklittle> dug asks for clarification.
<marklittle> Geoff GetStatus already has extensibility element in there. So why not just use that?
<marklittle> dug an interoperable solution isn't possible that way for getting all properties of subscription unless we specify it in the specification. Could add an optional parameter to GetStatus but that feels like replicating transfer and duplicating functionality.
<marklittle> DaveS wants uniform management capability.
<marklittle> chair any objection to defining a standard XML representation to subscription manager?
<marklittle> Geoff not ready to do that yet.
<marklittle> resolution: point 1 to proposal removed by consensus.
<marklittle> li defining representation for subscription manager means resolving another EPR related issue: when do subscribe get back subscription manger EPR but no definition of how to take an EPR and get resource from it?
<marklittle> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6850
<marklittle> remove it
<marklittle> +1
<gpilz> +1
<marklittle> chair any discussion?
<marklittle> Wu wants to keep it. Eventing doesn't have a direct reference to SOAP. Eventing should have it. Benefit to the statement so that people can see it has value outside of SOAP.
<dug> By using the XML, SOAP [SOAP 1.1], [SOAP 1.2], and WSDL [WSDL 1.1] extensibility models, the Web service specifications (WS-*) are designed to be composed with each other to provide a rich set of tools to provide security in the Web services environment.
<marklittle> dug eventing does talk about SOAP.
<marklittle> gpilz thinks Wu's assertion is not correct. Well understood design patterns for pub/sub. WS-Eventing is about this pattern in SOAP. That is its reason for existence.
<marklittle> +1
<marklittle> Wu thinks semantics of ws-e can be applied to non-SOAP environment and that ws-e is more than pub/sub. Removing SOAP reference removes value as well to ws-e.
<marklittle> -1 to Wu
<marklittle> gpilz if we push ws-* useful outside of SOAP then it's a long troubled road.
<Wu> WS-E semantics are defned depending on SOAP and we should not confine ourselves to only for SOAP.
<marklittle> +1 to gil. We shouldn't compete with OMG, JCP etc.
<Wu> s/defined depending/defined NOT depending/ on SOAP
<marklittle> dug removing sentence doesn't change anything, so Wu argument that it would change the meaning that we can't use ws-e outside of SOAP is not valid. Having it is inconsistent.
<marklittle> Wu agrees.
<Wu> I am more friendly to it.
<marklittle> chair any disagreements on proposal? none.
<marklittle> chair can we resolve according to proposal? Yes.
<marklittle> resolution: issue is resolved as per proposal.
<gpilz> what did I do?
<marklittle> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6594
<marklittle> Geoff has been discussing with dug around wording. Dug has suggestion by separating concept of changes and additional requirements to the spec. Can treat them separately and let the first part of this proposal to go through.
<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0162.html
<asir> in cricket, it is called a hatrick
<marklittle> 6594 6672 6673
<Bob> N.B. this resolves 6594, 6672, 6673
<marklittle> Geoff take action item to open new issue on closing these issues.
<marklittle> chair can we take proposal to resolve 6594, 6672 and 6673 with document attached to http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0162.html. Any objections?
<marklittle> ;-)
<marklittle> just ;-)
<marklittle> chair no objections. resolved.
<marklittle> resolution: resolved 6594, 6672 and 6673 with document attached to http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0162.html
<marklittle> chair let's not push our luck and go have a few drinks of wine ;-)
<Yves> trackbot, end telcon
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) WARNING: Bad s/// command: s/resolved/resolved as per bugzilla issue/p FAILED: s/and an problem is detected/and a problem is detected/ Succeeded: s/and an problem is detected/and a problem is detected/ Succeeded: s/+q/q+/ WARNING: Bad s/// command: s/defined depending/defined NOT depending/ on SOAP Found Scribe: Miar Little Found Scribe: Mark Little WARNING: 0 scribe lines found (out of 270 total lines.) Are you sure you specified a correct ScribeNick? Scribes: Miar Little, Mark Little Default Present: Bob_Freund, [Microsoft], asir, Mark_Little, [IBM], Tom_Rutt, doug, Wu_Chou, +0125669aaaa, Dave, +0208234aabb, +0208234aacc, Gilbert, Ashok_Malhotra, Yves, +1.571.262.aadd, JeffM, +2, +0125669aaff, Katy_Warr Present: Bob_Freund [Microsoft] asir Mark_Little [IBM] Tom_Rutt doug Wu_Chou +0125669aaaa Dave +0208234aabb +0208234aacc Gilbert Ashok_Malhotra Yves +1.571.262.aadd JeffM +2 +0125669aaff Katy_Warr Agenda: http://lists.w3.org/Archives/Member/member-ws-resource-access/2009May/0006.html Found Date: 12 May 2009 Guessing minutes URL: http://www.w3.org/2009/05/12-ws-ra-minutes.html People with action items:[End of scribe.perl diagnostic output]