See also: IRC log
<trackbot> Date: 30 June 2009
<Bob> Scribe: Wu Chou
Agenda agreed
minutes of 2009-06-23 are approved
August F2F hosted by Microsoft
asir: need the list of people who attend and will provide local information
bob: England F2F meeting - who thinks to attend - a quick poll
Asir: yes
dug: someone will be there from IBM
dave: yes
fred: No
Gil: yes
Li: no
Mark: ?
Ram: yes
tom: no
wu: yes
<Yves> Yves: yes
<DaveS> Dave: Yes
10 or more will attend F2F at England
issue 7068 accepted and Doug is the owner
<dug> This specification defines one ContentDescription URI,
<dug> http://.../ContentDescription/Literal, which can be used to convey to the
<dug> service that the children of the wst:Create element are not instructions
<dug> but rather are to be taken as the literal resource representation of the
<dug> new resource.
asir: there is another issue related to literal representation, what is the relation?
dug: this another issue
asir: no dependency
dug: yes
asir: would like more time
dug: remove this feature from RT and deal with it in issue 6411
ashok: this feature is about resource not fragment.
asir: we are fine to drop this feature from RT.
RESOLUTION: Resolve Issue-6699 by dropping the feature from RT w/o
dug: examining inside EPR is problem. The identifier should be removed.
<gpilz> +q
<dug> Implementations of Event Sources, or Subscription Managers, MUST NOT assume that this reference parameter will be used.
gpilz: prefer to address this issue with some clarifying text as opposed to remove it
asir: my suggestion is in line with Gil to clarifying it.
dug: add some text e.g. implementation ...
<DaveS> +
<dug> I can live with #2 but I reserve the right to say "I told you so" later :-)
asir: close it with some email if all agree with clarifying text
<dug> +q
dave: would like to live option 1
bob: two choices - remove+some clarifying text (thumb up) or delete it (down)
asir: up
dug: down
dave: down
fred: abstain
gil: down
<dug> LOL
li: down
ram: up
sreed: down
tom: down
yves: abstain
bob: more down than up
asir: my suggestion looking at proposal more
DaveS: like to know the value to bother proposal up
asir: Iook at the Primer example
<DaveS> Do we have a link for the primer?
gpilz: logically cannot be any interoperablity issue by removing this identifier.
<asir> Please see section 6.3 in http://www.w3.org/2002/ws/ra/9/01/UnderstandingWebServiceResourceAccess.pdf
dug: agree with Gill
asir: posted the link to the use case
to irc
... Section 6.3 use case
<gpilz> wsu:Id
dug: use case does not say it must be this identifier. Otherwise, it will be a problem.
<dug> or a query param :-)
DaveS: it looks like a topic for Primer, not for the specs.
<DaveS> +1
<dug> +1 gil - it can't be about interop
<Bob> +1
Bob: more discussion on this point?
asir: I would like to look further
Bob: next week?
<DaveS> [My network here in Japan keeps droping the IRC, so next time it goes, I'll just leave it.]
<gpilz> is there a link to this doc?
<li> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0052.html
asir: presenting the proposal based
on F2F WG decision - using Qname and remove mode
... At high level, retain the delivery element, delete mode, using
Qname, etc.
dug: some sections are really nice.
agree delivery element. Questions about delivery pattern.
... delivery pattern adding a level of complexity. I have a draft
proposal.
gpilz: ws-eventing may not have a lot of control on extension works.
asir: we are open to the name of delivery pattern.
bob: Qname is the agreed direction at F2F
tom: dug rewording has a delivery element further down
<li> wu: we need to read more about doug's proposal
<dug> http://www.w3.org/2002/ws/ra/9/06/wseventing-DeliveryElement.html
asir: push mode is gone in doug proposal
dug: present his proposal.
bob: if Geoff and Doug can work together to address the differences, I would like to be on the call
<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0070.html
bob: introduce his proposal
DaveS: I am quite happy with this.
ram: would like to see some concrete proposal
dug: 1 and 3 may be o.k., 2 needs details. he can live with it
asir: we are currently exploring these options, need concrete proposal
Yves: preferable for a separate specs
<asir> +1 to separate spec for frags and link it to Transfer
<asir> agree that we need a concrete proposal
Yves: need a better details to move forward
bob: can folks live with points 1 and 3?
asir: we can live with 2 and 3.
... can we have one more week to look into these options?
bob: o.k.
gpilz: my proposal 6401 may help this issue.
bob: do we agree with the problem
statement?
... we should not preclude topics support
<li> i made some use cases here: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/0176.html
dug: i do not view this an optimization, may or may not be faster
bob: Li can you start to push forward on this?
<Yves> trackbot, end telcon