See also: IRC log
<trackbot> Date: 25 August 2009
<Bob> trackbot, start telecon
<trackbot> Meeting: Web Services Resource Access Working Group Teleconference
<trackbot> Date: 25 August 2009
<Bob> scribe: Li Li
<Bob> scribenick: Li
agenda agreed
<Bob> minutes link http://www.w3.org/2002/ws/ra/9/08/2009-08-18.html
RESOLUTION: Minutes of 2009-08-18 accepted
Yves confirms that he will be able to chair
Logistics info at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0071.html
ram had some comments
dug and ram figure out which comments and agree they are resolved
<dug> comments at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0055.html
RESOLUTION: Incorporated resolutions in 2009-07-24 snapshots of mex and rt accepted
Bob: Notes that good progress has been made on action items and and reminds members to keep an eye on due dates
ram: needs a few more days to polish
bob: fpwd needs to be out by sept (next month) in order to hold our schedule
ram: that's acceptable
bob: objection to proposal?
RESOLUTION: Issue-7365 resolved as proposed
<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0070.html
Dug: explains issue and proposal
<dug> ** New dialect
<dug> definitions MUST include sufficient information for proper application.
<dug> For example, it would need to include the context (which data) over which
<dug> the filter operates. ***
bob: append proposed text to previous proposal?
asir: when does context change?
dug: context of xpath changes from envelope to event data
context may change for other uri too, like actionURI
Asir: i don't recall discussing change of context being discussed
<dug> "... a new dialect might be defined to support filtering based on data not included in the notification message itself."
Gil: generic use of xpath is insufficient as it doesn't tell the context
therefore, ws-e needs a new uri to convey the context
Asir: it's new to me that uri indicates context
Dug: filter always needs context
Tom: do we need context to complicate thing?
Dug: yes, we have filter on action, topic, etc. beside just event data itself
Asir: uri needs to point to stable xpath
Dug: maybe to separate flexibility to another issue
Bob: we can define a uri for backward compability, folks will be able to define a filter accordingly
Asir: it's ok if this is a simple case
<asir> Asir: if we were to define our own namespace name then this would be a unique case and not set any precedence
Dug: we have to do it as gil explained the use cases
Asir: it's not clear what is replaced
Dug: two parts: one is to swap out uri; the other is the text
<dug> new text is in: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0070.html
figuring out the consolidated proposal...
asir: make uri to xpath 1.0?
daves: a different uri for xpath 2.0 then?
<asir> Here is the draft proposal
<asir> 1. Append to Section '[Body]/wse:Subscribe/wse:Filter/@Dialect
<asir> '
<asir> *** New dialect definitions MUST include sufficient informalion for proper application. For example, it would need to include the context (which data) over which the filter operates. ***
<asir> 2. Replace http://www.w3.org/TR/1999/REC-xpath-19991116 with http://www.w3.org/2009/02/ws-evt/Dialects/XPath10
<dug> 3. and similar for enum
bob: any object to the above proposal to 7235?
RESOLUTION: Issue-7235 resolved with proposal above without objection
<dug> Unless otherwise noted, all URIs are absolute URIs and URI comparison MUST be performed according to [RFC 3986] section 6.2.1.
<Ram> test
yves: it's better to stay within uri instead of iri
Bob: any objections to the proposal?
ram: any exception to the general rule?
dug: i couldn't find any...
RESOLUTION: Issue-7270 resolved as proposed
RESOLUTION: Issue- 7160 resolved as proposed
RESOLUTION: Issue-7426 accepted as a new issue
bob: ban the use of iri where uri comparison is used?
<dug> can we see some text?
AI for yves to propose text for 7426
<asir> ACTION: Yves to propose text for issue 7426 [recorded in http://www.w3.org/2009/08/25-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-97 - Propose text for issue 7426 [on Yves Lafon - due 2009-09-01].
<asir> Didn't you resolve it last week?
<asir> doubly resolved!
RESOLUTION: Issue-7196 resolved (or resolution confirmed)
yves: explains the issue
dug: why do we need this?
yves: we need to specify the property of that operation
dug: do we need to do the same for "getstatus"?
yves: we should spell out for all safe operations
<gpilz> +1
dug: then we need to apply it to all specs
asir: why not idempotent?
<asir> Here is a link to Feb discussion ... http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0045.html
yves: we could do that if people like it
gil: this is a constraint on
implementations
... we should do it for other specs as well
<dug> +1 obviously
gil: find all safe operations first
<scribe> ACTION: yves to include all safe operations in all specs [recorded in http://www.w3.org/2009/08/25-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-98 - Include all safe operations in all specs [on Yves Lafon - due 2009-09-01].
gil: explains the new proposal 6401
looks ok to me
<dug> interesting - I'm missing the section header for appendix A when I look at the html version too - but the word doc is ok
dug: some editorial changes, remove duplicates about mex
<Bob> Dug presents an amended proposal
<Ram> I would like to understand this sentence in Dug's revision: "An Event Source there MUST NOT exist more than one EventDescription document."
ram: why that constraint?
dug: it's in the original proposal
gil: more than ED document complicates relations to NW
asir: i don't fully understand the
requirement
... to relate ED and NW
dug: one ED doc should be returned,
more than one adds complexity
... one ED doc hides complexity
asir: multiple docs is supported by mex in multi sections
<Zakim> dug, you wanted to ask a clarifying question
dug: what subscriber do with multi docs?
asir: client handles multi-docs according to the standards
gil: we are profiling mex
... we make it clear how different parts are related
<asir> Gil - i was only trying to help you! Nothing more.
<dug> sorry - power went out
gil: if two ED docs and two NW docs are returned, then which goes which is not clear
<asir> Vow .. are we closing 6401?
+q
<dug> never! :-)
<dug> I can send in a new rev with the typo that Ram noticed fixed
<dug> if people want
li: would like to read it
ram: we would like to postpone it until next week
bob: review dug's proposal next week as basis of 6401
<DaveS> Goodnight
<gpilz> good job li!
bob: declare victory for today...