See also: IRC log
<trackbot> Date: 12 May 2009
<scribe> scribe: Mark Little
<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/
<scribe> chair: comments on agenda? none.
<scribe> chair: any objections to approval minutes from May 5th? None. Accepted.
<scribe> chair: has there been enough time to look at incorporated issues? Some indication that more time needed. One more week extension.
<scribe> chair: asks for status update
gpilz: making progress. couple of issues remaining but no main problems or disagreements at this stage.
<scribe> chair: what is expected completion date?
gpilz: what's expected?
<scribe> chair: closure of issue 6401.
<asir> closure?
<scribe> chair: resolution of 6401 direction would be sufficient so we could then work on text. Though text would be better. What is problem?
<scribe> chair: why not just forward proposal for discussion?
<scribe> chair: will put this back on the agenda for next week. Would like to see something to discuss before then if possible.
Wu: posted already.
<scribe> chair: if version posted by Wu is good enough, let's start discussions around it. Move commentary to public list.
<scribe> chair: none currently.
<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6860
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6860
gpilz discusses issue and asks if there are any concerns over removing wsen:EnumerationContext?
<scribe> chair: everyone ok with proposal? no objections.
resolution: 6860 resolved
s/resolved/resolved as per bugzilla issue/p
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6696
<gpilz> change s/and an problem is detected/and a problem is detected/
Geoff fine in general, but "If this check is performed and an problem is detected then the event source MUST generate [fault]". Only place in spec with MUST other than MAY. Why?
dug generating is different from transmitting.
Geoff should be consistent though. Either all MUST or all MAY. If former then we should raise another issue to make them all MUST.
dug agrees.
+1
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.
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.
Geoff it says it "SHOULD have some cursory validity" But maybe MAY?
dug prefers SHOULD as it's a recommendation. Pious advice is better.
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.
dug UnsupportedEPR?
DaveS limit it to checking semantic validity of EPR then it's accurate as InvalidEPR.
<scribe> chair: change InvalidEPR to UnusableEPR?
<gpilz> For example, an unsupported transport specified within the wsa:Address IRI.
Geoff any way we can be more specific what cursory validity checking means? Seems vague.
dug yes, that's deliberate. Didn't want to be specific. Leave it to the implementation so they can choose what they can check.
dug open to stronger wording if we can agree on it.
Geoff would prefer some stronger wording. Just not sure what that is.
dug maybe a separate issue? So we can close this one?
Geoff yes, will create another issue later.
<scribe> chair: reviews two changes. Everyone willing to adopt?
<gpilz> change s/and an problem is detected/and a problem is detected/
<Bob> also change MUST/MAY
<Bob> and s/InvalidEPR/UnusableEPR
<scribe> chair: no objections.
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
<Bob> That is what I heard the group agree to
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.
DaveS checks that cases where part of description can be updated and part may not be. Transfer supports this, correct?
dug yes
<asir> :-)
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.
Geoff Seems like pointless thing. Why not add it and have it in conjunction with existing interfaces?
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.
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?
dug not my intent to break the semantics.
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?
Katy thinks it's an interesting proposal.
<scribe> 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)?
dug that's an implementation detail.
dug maybe this is a general transfer question?
<DaveS> Dave dropped briefly
<dug> LOL blame me???
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
<scribe> 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
<scribe> 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.
<scribe> 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?
Geoff what's difference between this and having GetStatus being extensible so that certain event sources can return more information?
dug asks for clarification.
Geoff GetStatus already has extensibility element in there. So why not just use that?
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.
DaveS wants uniform management capability.
<scribe> chair: any objection to defining a standard XML representation to subscription manager?
Geoff: not ready to do that yet.
resolution: point 1 to proposal removed by consensus.
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?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6850
remove it
+1
<gpilz> +1
<scribe> chair: any discussion?
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.
dug: eventing does talk about SOAP.
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.
+1
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.
-1 to Wu
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.
+1 to gil. We shouldn't compete with OMG, JCP etc.
<Wu> s/defined depending/defined NOT depending/ on SOAP
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.
Wu agrees.
<Wu> I am more friendly to it.
<scribe> chair: any disagreements on proposal? none.
<scribe> chair: can we resolve according to proposal? Yes.
resolution: issue is resolved as per proposal.
<gpilz> what did I do?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6594
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
6594 6672 6673
<Bob> N.B. this resolves 6594, 6672, 6673
<scribe> ACTION: Geoff to open new issue on extensibility concerns related to issues 6594, 6672, 6673. [recorded in http://www.w3.org/2009/05/12-ws-ra-minutes.html#action01]
<scribe> 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?
;-)
just ;-)
<scribe> chair: no objections. resolved.
resolution: resolved 6594, 6672 and 6673 with document attached to http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0162.html
<scribe> chair: let's not push our luck and go have a few drinks of wine ;-)
<Yves> trackbot, end telcon