See also: IRC log
<trackbot> Date: 04 January 2011
<Client> scribenick: li
bob: agenda approved
... minutes approved
<dug> Gil - the f2f is at redwood shores, right?
bob: microsoft is ram + 1,2
... no pre registration needed to attend f2f
<Client> New issue http://www.w3.org/Bugs/Public/show_bug.cgi?id=11667
bob: the above issue is opened
<dug> options: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Dec/att-0028/00-part
gil: discuss approaches to 11667
... incline to support both
wu: fine with that
gil: i can come up needed text in ws-e 2.3
<gpilz> Add the following sentence to the end of the 2nd paragraph of Section 2.3: Conformant Event Source implementations MUST support both wrapped and unwrapped notifications.
dug: how about in 3.4?
<dug> http://www.w3.org/2002/ws/ra/edcopies/wsmex.html#Compliance
bob: resolution to 11667 per gil's
sentence in ws-e 2.3
... 11667 resolved w/o objection
<Client> http://lists.w3.org/Archives/Public/public-ws-resource-access/2011Jan/0003.html
bob: there is a mime type proposal for the issue in the link
gil: describe his proposal per wsdl 2.0 approach
<Yves> actually, you should look at 3023bis, even if 3023 is the current "stable"
discuss problem with mime type and URI fragment
dug: rename name to id to avoid conflict
yves and gil: sounds fine
tom: id is ncname
<Ashok> From XML Schema: The 'value space' of ID is the set of all strings that 'match' the NCName production in [Namespaces in XML].
bob: issue 11551 resolved w/o objection (replace name attribute with id in evd)
dug: can do these changes tonight
gil: will not implement xpath in ws-e
dug: intend to do as many as possible
bob: mark optional features w/o
implementation as "at risk"
... and they will disappear
... propose to mark all optional features "at risk" going into
CR
... unless there are at least two implementations?
dug: what qualifies as implementation, e.g ws-policy?
bob: implementation exhibits required behaviors
dug: what does an implementation need to do keep ws-policy?
bob: policies in wsdl I think would be sufficient
katy: we can test server behavior associated with policy
<Katy> We can test that service errors indicating non-support should not contradict advertised policies
ashok: two wsdl with different policy should have different behaviors
dug: expose policy in wsdl is enough?
gil: policy associated behaviors can be hard-coded or tool derived, therefore it is hard to decide which was done
katy: behaviors exposed by policy should not be contradicted by protocol messages
bob: we do need to test policy are well-formed
tom: there is no need for test cases for policy
bob: mark all options at risk or
everyone marks those to implement in week?
... to point feature list locations and AI to mark them up
... need to resolve issues in remind status
<Client> test scenarios http://www.w3.org/2002/ws/ra/edcopies/scenario.html
ram: is there a separate doc for ws-enu?
bob: folks need to mark feature list as implemented, not implemented, or dont know
<dug> ram: http://www.w3.org/2002/ws/ra/edcopies/scenario.xml and there are some templates in the enum section that nathan can follow
bob: defer primers to after test cases