W3C

- DRAFT -

Web Services Resource Access Working Group Teleconference

12 May 2010

Agenda

See also: IRC log

Attendees

Present
[Microsoft], +1.571.262.aaaa, +1.571.262.aabb, Vikas, asoldano, Yves, li
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Tom_Rutt

Contents


<trackbot> Date: 12 May 2010

<Bob> scribenick: Tom_Rutt

Agenda

agenda accepted

New issues

All three new issues were accepted unanamously

Issue 9712

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9712

No objection to accept proposal

Resolution: close 9712 by resolving as proposed

Issue 9713

-Issue-9713 GetStatusOperationSupported and UnsubscribeOperationSupported parameters not needed http://www.w3.org/Bugs/Public/show_bug.cgi?id=9713 -Pilz

Gil: they must be supported by all subscription managers. There is no optionality.

Wu: when did we decide to make these madatory?

Ram: the definitions of the operations state they must be supported.
... we decided to do this two face to face meetings ago, in Santa Clara

No objections to accepting resolution..

Resolution: Issue 9713 resolve by accepting proposal

Issue 9717

-Issue-9717 Frag: Add pre-defined dialect for Xpath 2.0 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9717 -Freund

Dug: Is this only for Frag. We define Xpath 1.0 in eventing as well.

Bob: It is intended for all three specs.

Dug: should the new section be written just like the 1.0 section of these documents.

No objection to applying to eventing, enum, and frag

Resolution: Issue 9717 resolved as proposed

Issue 9700

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9700

Dug: he is looking for info in get metadata response as to what supported types are
... He does not want to rely on policy

Gil: I do not understand why a get client who asked for a type, would be interested in other types.

Dug: If the client can deal with other types, they can use an "all" in the get metadata. He did not seem happy with this suggestion

Ram: It seems that a fault, with the additional information, would satisfy him

Dug: a fault is not appropriate, since there might be multiple metadata types in a single request, to fault all of them is not useful
... I think relying on interrogating policy is the best approach.
... I would not like to tweek the protocol, when policy can meet the need

Gil: I agree with Dug. Policy is the way to do this. If this a problem that people want to profile out, why not just remove the content attribute?

Dug: we need to give the client a way to select which types it wants
... I cannot accept removing the attribute. Let them rely on policy
... for each dialect you support, you can list the type and format you support. In section 12

Gil: content attribute is optional, they can just say conformant profile clients cannot send the optional attribute. However, the server must be able to accept the attribute.

<gpilz> we don't like using the mics

Bob: I am hearing that the mechanisms are available, and their profile can require that clients not send the content attribute.

<gpilz> we're shy

No objection to close with no action

<Yves> gil :)

Resolution: Issue 9700 closed with no action

<scribe> ACTION: Ram will write the response to the originator of issue 9700 [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action01]

<trackbot> Created ACTION-157 - Will write the response to the originator of issue 9700 [on Ram Jeyaraman - due 2010-05-19].

Issue 9709

<Dug> http://www.w3.org/Bugs/Public/attachment.cgi?id=876

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9709

Dug: I modified the text around the getWSDLResponse/xs:any to allow references as well as the wsdl itself

added text description

[Body]/mex:GetWSDLResponse/xs:any

When the GetWSDLResponse element contains any child elements, the first element MUST either be the WSDL metadata document, or a reference to the WSDL metadata document, of the endpoint. Any extension elements MUST appear after the WSDL document/reference. The absence of any child elements indicates that the endpoint does not have any WSDL document, or additional metadata, associated with it.

<Yves> How can a small device gain something by retrieving the same data using a new request/response insted of having the data inline. the mex env is not that big

Dug: the use case is that the endpoint does not have the entire copy of the wsdl, however they have a pointer to where the wsdl can be obtained

His third sentence seems to imply he is concerned about the server's requirements, not the client's

<Yves> returning a reference might help caching as well

Dug: we could suggest that the first choice is the raw data itself, only sendting the location or reference is the data is not available

Gil: If we are concerned about the client requirements, we may need an attribute on the request, like the content attribute
... Antoine's concern is for the server. The client can do get metadata. Leave it to the service to decide. The client would use whatever means it is presented with in the response.

Tom: what if the server wants to decide not to send the data for a short period, say due to network load. I think a mandate as to the preferred way to respond is untestable anyway

Dug: I can live with it being totally up to the server

Bob: is accepting the proposal acceptable to everyone?

No objections raised

Resolution: Issue 9709 resolved as proposed

<scribe> ACTION: Dug to write the response to the reviewer Antoine [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action02]

<trackbot> Created ACTION-158 - Write the response to the reviewer Antoine [on Doug Davis - due 2010-05-19].

Issue 9610

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9610

Dug: why call it a pseudo event?

Bob: also correct the spelling

Gil: I would think that a reasonable implementation would try to poke the event source before it returns the success response to the verify, otherwise a fault could be sent.

Tom: did you define a specific fault?

gil: in soap 12 speak it would be a receiver fault.

Tom: could we add a note on the intent of the success reponse

<gpilz> Note, it is expected that implementations will not send the VerifyResponse until they have taken the necessary actions to cause the notification of the verify event to be transmitted.

<gpilz> This allows the implementations that are experiencing internal errors to transmit a fault in response to the Verify request.

Dug: what fault would you send?

Gil: a receiver fault indicating an internal error would suffice

Dug: what is the difference between this fault, and the sequenceEnd with an EndTo present

Gil you can get this fault to the verify, but still consider the subscription as being active. It could be a short term error condition

Li: would would be the infoset for the verification event. There is no parts for the message.

Gil: an empty soap:Body is ok, since the information is in the WSA:Action value

Gil I do not understand the relevance of InfoSet in this matter

Wu: the verification event could contain information about the subscription

Gil: the verify event is the same as any other event which can be sent from the event source, other than the fact that is is never filtered

Wu: carry in the verify event which particular verify request invocation is being responded to

Tom: he seems to be asking that the verify event report carry the message id for the verify request that stimulated it

Dug: why would we need that

Wu: It could give information on the delay between the request and the event emission. It would also allow detection of verify requests which never resulted in a verify event. More diagnostic information is available

Dug: Wu's proposal requires more complexity in the communication between the subscription Manager and the event source. Also it implies a complicated set of analysis by the event sync

Wu: I would prefer that we have time to think about this further

Gil: This extension to correlate verify event with the verify request is going beyond the requirements behind this issue. Timing aspects of the path verification are not required for the use case.
... I do not see the relevance of the infoset problem.

<gpilz> Note, it is expected that implementations will not send the VerifyResponse until they have taken the necessary actions to cause the notification of the verify event to be transmitted. This allows the implementations that are experiencing internal errors to transmit a fault in response to the Verify request.

Dug: I can live with the implementation note. However, I would like to see more information on the types of fault that may be returned. When would that fault not be bad enough to kill the subscription?

Tom: there might be a temporary condition causing the lack of communication between the sub manager and its event source.

Gil: The client receiving this fault without a subscription end would tell the client it can try the verify again at a later time, with the potential of success

Wu: we would like time to consider extension to the simple proposal, which may make it more useful for other use cases

<gpilz> ws-man v1.1 says this about the heartbeat event: "The heartbeat event itself is simply an event message with no body and is identified by its wsa:Action URI as follows: . . ."

Ram: we could modify the get status semantics to require that the sub manager only return a success if it knows the event source is alive. That would cover this requirment

<gpilz> q

Tom: Ram's suggestion covers half of the requirement for heartbeat, It would not also verify the communication path between an event source and its event sync, in the case where the event source is at a different sending port than the port used by the subscription manager get status response

Gil: it is not possible for the event source to verify its link to the event sink.

<Yves> do we need to check everything, from the path between the sub manager to event generator, to the even generator and receiver?

Bob: to turn this into a network diagnostic would require a lot of additional mechanisms to be in place.

Dug: there may be proxies between the event source and the event sink

Bob: it is difficult to think of all the possible failure modes in this kind of a "ping" mechanism. We need to restrict our discussion to finding a proposal to meet the needs that issue originator brought forward, with sufficient widespread use to make it part of the base eventing spec.
... they are asking for a heartbeat mechanism to figure that both the event source is alive, and also that the communication channel between source and sink is functioning.

Gil: I would hate to see this issue hold up our specs. If we cannot agree to a simple solution that meets there needs, I would prefer to close with not action

Wu: how about modifying the get status operation to have the get status response be returned from the event source to the event sync

Gil: That would cause more problems than it solves. The get status requester may not be the same as the event sink

<Yves> get status through the event sink is a bad solution, even delivery and status checking are two different things

Gil: perhaps the verify feature could be triggered by an extra parameter to the get status.

Dug: I think that it makes sense to have the information on the get status response to be returned in the verify response. Why do we need two operation types, if an option on get status could add the triggering of verify event

Bob: who in in favor of changing the proposal to adding an optional verify element to get status to also do the verify event trigger.

Several indicate that if we do anything for the verify, we should merge it as a feature of get status.

Only Fujitsu and Oracle indicated that this new verify feature be added to get status.

Wu: I could accept such an addition if if did more than the simple proposal.

Bob: can we have a decision by Thursday morning?

Agreed that we will schedule decision for Thursday morning of F2F.

Issue 9675

<Dug> http://www.w3.org/Bugs/Public/attachment.cgi?id=875

-Issue-9675 Eventing: Clarify attachment of NotificationWSDLs to the EventSource policy assertion http://www.w3.org/Bugs/Public/show_bug.cgi?id=9675 -Mensch

Dug: I did what we agreed to yesterday.

Gil: I would like to remove the word "only" in the second line of the explanation for the example.

Dug: I can live with removing the word "only", it is true but I agree not necessary

No objection to accepting amended proposal

Resolution: Resolve Issue 9675 with proposal as amended by striking word "only"

Issue 9701

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9701

dug: there is no requirement for event source to understand anything other than NotifyTo element. He wants a fault when the event source cannot accept an extension

Bob: we had this discussion at past F2F regarding the usual soap extension model.
... why do we need a fault, why not just eliminate the sub manager epr from the response?

Dug: we are really trying to say that there must be some delivery mechanism present. However the wording puts it in xml speak. He would rather have a fault, rather than just creating the subscription after ignoring extensions

Gil: they want new fault, "I recognize there is something extra in the request, but I do not know what to do with it"

Dug: define "no delivery mechanism fault" when there are not children elements, or no elements which are understood by the event source

Gil: but I might understand, but do not want to support the mechanism.

Bob: Fault when no delivery mechanism has been established.

<Dug> NoDeliveryMechanismEstablished

Agreed to have Dug write a full proposal which reflects the discussion above.

Resolution: Resolve Issue 9701 by adding new Fault "NoDeliveryMechanismEstablished" with appropriate explanatory text

<scribe> ACTION: Dug to write response to issue 9701 reviewer explaining our solution to his issue [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action03]

<trackbot> Created ACTION-159 - Write response to issue 9701 reviewer explaining our solution to his issue [on Doug Davis - due 2010-05-19].

Issue 9702

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9702

Gil: Antoine seems to assume you can profile out features that the base spec states you MUST support

Dug: you have to understand these attributes, while you do not have to support all the values

Gil: this is a sender optional feature, thus the service must be capable of handling it when present. They could profile as "conforming clients in this profile MUST NOT include this in the request message
... they seem to be worried about clients which do not conform to the profile. The only way to give him what he wants is to change the definition of this feature being both client and server optional
... you would have to add a policy parameter for this, and also add a fault to indicate the server does not support it.

Dug: what if the server supports the syntax, however it never can satisfy any value in the expires. It can send the existing fault all the time

Gil: we could make the entire expiry mechanism to be server optional. The policy and fault would be indicating non-support of entire expiry mechanism. The other alternative resolution is close No Action

Dug: another alternative is only allow a duration for expiry. Get rid of min and max

<Dug> and exact

Bob: for servers that do not support ranges of time, they will simply respond to the max value

Gil: the server can just pick the max and give it to the subsription

Dug: they want to have the server to be able to pick the expiry time, irregardless of what the client requests
... the spec requires that the server check that min is smaller than the max, otherwise fault the request
... how about "no expires element -> server choice" , "Exact time, if present must be honored to create subscription"
... also have expires be server optional

Gil: I would like to get rid of date/time, and rely on duration only

<Dug> Expires is server optional, add a fault for when its not supported, add a ExpiresSupported policy assertion, Subscribe w/o Expires == server chooses, Subscribe + Expires == match the time/duration or fault

No object to the above as a directional resolution

Agree to finalize decision on Thursday morning

Reconvene at 1:08 PM

Issue 9700 Response

Dug: if the content attribute is not present, the default is any format. However, they cannot profile out the server behaviour when the content attribute is present but not supported.
... when the content attribute is present, the server must support it or not accept the request.

Issue 9703

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9703

Review event descriptions and their attachment mechanisms

<Dug> http://www.w3.org/Bugs/Public/attachment.cgi?id=878

Dug: one thing Antoine is concerned about is the potential duplication when the same event type is associated with more than one wsp:Policy assertion type
... he wants an element in the wsdl descriptions doc which has list of event types. This element is referred to in the wsp:Policy.
... he is adding the wse:Notification element to policy eventSource which has an attribute pointing at that element in the descriptions doc.
... He wants to be able to have everything in a single document, and also have reuse of the definitions in that single document.
... rather than adding this notifications element to the policy assertion, have the mex:Location to have a relative URL so it can point to EVDs that are embedded within the same doc.
... this would be a change to the mex spec to allow relative url, and also to the event spec to allow multiple event description elements within the event source assertion.
... I have some concerns about the relative URL. we would have to use the wsu:Id attribute

Gil BP does not allow wsdl description extensions to be required.

Dug: I like this relative URL better than using a QName pointer mechanism
... my proposal would still put the event description in the wsdl, but changes the way it is pointed at.
... for the Notification WSDL , his QName points to a port type
... my proposal again allows mex:Location to be relative. the mex:Location would have a Type attribute.
... notion of relative URI for mex:Location is a change which can be justified on its own right. The change is allowing more than one event description to appear, and a reference for the wsdl element.
... our event source assertion needs to describe what happens when there are multiple instances appearing inside it.

Gil: I would like some time to think about this one.

Agreed to defer decision until Thursday at this F2F

Issue 9671 resolution incorporation into spec

<Dug> http://www.w3.org/2002/ws/ra/edcopies/wsmex.html

<Dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0024.html

In addition to the edits in Katy's

proposal, the following additional things were changed:

- Updated xsd

- Updated wsdl

- Added Content to DeleteMetadata request (more below)

- Added the Fault boilerplate text to the new "Faults" section

- Added the boilerplate text to the Notational Conventions section about

"generate"

- Added a ref to the WSA SOAP Binding spec - due to the new faults section

- Added ... to GetMetadataResponse pseudo-schema

Dug: ... I want everyone to be aware of the changes I made, and to ensure that I did not make any mistakes during editing

<Dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0024.html

I've included two word docs - one is a diff of the final mex spec against

the mex spec prior to these edits, and one is a diff of the mex spec

against Katy's proposal. This will allow people to see the edits from two

different perspectives. FYI - some of the diffs in the *-katy-diff.doc

are due to the other issues we resolved today not being part of Katy's

version - so you can ignore those change bars.

http://www.w3.org/2002/ws/ra/10/05/wsmex-9671-diff.doc

http://www.w3.org/2002/ws/ra/10/05/wsmex-9671-katy-diff.doc

Issue 8284 References to wsdl 1.1 corrected version of schems

Gil: We have a proposal on the table of the BP group on this topic, and are working hard to partitioning the section on wsdl into two sections: Changes to Wsdl spec vs Profiling of WSDL requirements.

Bob: open issues include 8284, Heartbeat/verify, Expiration time not supported, Event descriptions attachment mechanisms

All but 8824 are scheduled for decision Thursday of this F2F

At Risk Determination and Testing

Bob: our charter requires for each feature in spec, in order to exit CR we need to have two independent implementations that implement those features
... we need to get an Idea of which parts of the spec companies are not planning to implement

Company, Enum, Event, EVD, Trans, Frag, SA, Mex

IBM, ?, I, I, I, I, I, I

MS, I, I, ?, I, I, ? I

ORCL, ?, I, I, ?, ?, I, ?

Avaya, X, I, X, X, X, X, X

Fujitsu, I, I, ?, ?, ?, ?, ?

Hitachi, I, I, ?, I, I, ?, ?

Bob: we need to poll CA, SAG, and Red Hat

Key: ? Thinking, X Won't, I Intend date TBD

Bob: I propose to all to look at SoapUI as a tool to employ for testing
... we need to get the people from each company who will be doing the test implementations together
... we will be testing the spec in a behavioral sense. Not a man in the middle network sniffing based approach (such as done in WS-I)
... for each of these specs we have to determine on a feature by feature basis which features will be implemented by at least two implementations

s/\? I/\?, I/

Bob: we need to convert all the Intentions into a specific date . What is the Date that we have Dates ready by?

Dates for the Date

IBM 7/ Begin

MS 9/Begin

ORCL 7/ Begin

Avaya 9/ B

Fujitsu 9 / B

Hitachi 9/ B

<scribe> ACTION: Gill to catalogue eventing with an eye to which features might be at risk [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action04]

<trackbot> Sorry, couldn't find user - Gill

<scribe> ACTION: Gil to catalogue eventing with an eye to which features might be at risk [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action05]

<trackbot> Sorry, couldn't find user - Gil

<scribe> ACTION: gpilz to catalogue eventing with an eye to which features might be at risk [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action06]

<trackbot> Created ACTION-160 - Catalogue eventing with an eye to which features might be at risk [on Gilbert Pilz - due 2010-05-19].

Bob: Features in the CR marked at risk, will not be included in the Final Rec, if they have not met the implementation bar. Features that have not been marked at Risk in CR, will prevent the spec from reaching Rec status until those features reach the implementation bar
... how can we distribute out the specs to people to define the test scenarios and methods to test each feature in the feature catalogue

Dug: can the scenario doc be the same template for each ws-ra spec?

Gil: can we agree to basic principles for each scenario.
... E.G. any person who is not a member of the WG should be able to understand the contents of each test scenario

<scribe> ACTION: Dug to create a template for test scenario Doc to use for all of the WS-RA specs [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action07]

<trackbot> Created ACTION-161 - Create a template for test scenario Doc to use for all of the WS-RA specs [on Doug Davis - due 2010-05-19].

Gil: Mex needs a primer.

Bob: Katy has volunteered to write the primer on MEX

Next F2F

Feature Catalog volunteers:

Gil: Eventing, EVD

Katy - MEX

Ram - Transfer

Dug - Frag, SA

Dave S - possibly for Enum

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9607

review Responses to reviewers

<Bob> Please indicate your agreement or disagreement to this resolution by a reply to this email

Agreed we need to add above sentence to each response

Agreed to send response on 9607 to Gil with the added sentence

Response to Issue 9608 reviewer

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9608

agreed to add the additional para to Tom's suggestion: "the WG

believes that the number of potential items in the enumeration, while

interesting, isn't nearly as valuable as the total size of the

enumeration (total byte count of the data, not just the # of items).

This would allow for better pre-allocation of resources than simply

knowing the number of items. However, since calculating the total

size of the entire enumerated data set could be very expensive, the

cost of doing this at Enumerate() time didn't seem to be worth the

additional cost." as well as the boilerplate last sentence

Also make the bug number correct in the response (9608)

Topic Response to issue 9609

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9609

Agreed to send proposal from Gil on response

Topic Response to issue 9611

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9611

Dug: I an not happy with the first paragraph, since there is nothing in the spec which states you can put multiple event reports in a wrapped format (even if they have the same action value)

Wu: however we can do this today, without violating the ws eventing spec

Gil: I would not accept this unless we had a paragraph in the spec regarding whether the order is significant (e.g., switch open/ switch close / switch open). It would be dangerous to imply you can do this unless you have text stating the assumptions on ordering in time

Dug: we also have to be concerned about the faulting of specific event reports in the batch. We have not thought about this in the spec, so I do not like us implying this as a possibility in our response

Bob: how about removing the second sentence of first para

Also, remove "Beyond that, the group feels:" as the second para intro

Add the boilerplate last sentence

Wu: why cannot we add text to the spec regarding using wrapped to do some form of batching?

Bob: that would have to be raised as a new issue, it is not available at this time to put in a response to the ws-management group

Response to Reviewer of Issue 9612

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9612

agreed to send with additional boiler plate last sentence

Response to Reviewer of Issue 9613

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9613

Agreed to send as is with addition of final boiler plate sentence

<Ram> Proposed response: The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states [1] that when the Content attribute is not present it defaults to any content type. This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. Hence, there is no need for a fault for the service to indicate it does not support

Response to Reviewer of Issue 9700

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9700

Ram: I posted my proposed response just above

<Ram> The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states [1] that when the Content attribute is not present it defaults to any content type. This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. Hence, there is no need for a fault for the service to indicate it does not support a particular conten

Dug: in the compliance section of every spec we state that an optional element of a request MUST be able to be handled by a server, Unless the Spec has specific text allowing it as a server otion

<Ram> of Content attribute allowing a service to return any content type.

<Ram> The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states [1] that when the Content attribute is not present it defaults to any content type.

<Ram> This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format.

<Ram> Hence, there is no need for a fault for the service to indicate it does not support a particular content type. Thus, a profile could remove the use of Content attribute allowing a service to return any content type.

<Ram> [1] “When not present the default value is "http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Any".”

<Bob> The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states [1] that when the Content attribute is not present it defaults to any content type. This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. Hence, there is no need for a...

<Bob> ...fault for the service to indicate it does not support a particular content type. Thus, a profile could remove the use of Content attribute allowing a service to return any content type by a client. [1] “When not present the default value is "http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Any".

Add first para: in the compliance section of every spec we state that an optional element of a request MUST be able to be handled by a server, Unless the Spec has specific text allowing it as a server option

<Ram> Further, if the client wants a particular content type or format, it can request that by specifying that in the GetMetadata request.

<Bob> public-ws-resource-access-comments@w3.org

Response to reviewer of Issue 9558

Bob responded to Fred on this

<Bob> recessed until tomorrow at 9:00

Summary of Action Items

[NEW] ACTION: Dug to create a template for test scenario Doc to use for all of the WS-RA specs [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action07]
[NEW] ACTION: Dug to write response to issue 9701 reviewer explaining our solution to his issue [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action03]
[NEW] ACTION: Dug to write the response to the reviewer Antoine [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action02]
[NEW] ACTION: Gil to catalogue eventing with an eye to which features might be at risk [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action05]
[NEW] ACTION: Gill to catalogue eventing with an eye to which features might be at risk [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action04]
[NEW] ACTION: gpilz to catalogue eventing with an eye to which features might be at risk [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action06]
[NEW] ACTION: Ram will write the response to the originator of issue 9700 [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/05/12 23:52:54 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Succeeded: s/covers have/covers half/
Succeeded: s/not elements/no elements/
Succeeded: s/its not/its not supported/
Succeeded: s/above a directional/above as a directional/
FAILED: s/\? I/\?, I/
Found ScribeNick: Tom_Rutt
Inferring Scribes: Tom_Rutt
Default Present: [Microsoft], +1.571.262.aaaa, +1.571.262.aabb, Vikas, asoldano, Yves, li
Present: [Microsoft] +1.571.262.aaaa +1.571.262.aabb Vikas asoldano Yves li
Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0028.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 12 May 2010
Guessing minutes URL: http://www.w3.org/2010/05/12-ws-ra-minutes.html
People with action items: dug gil gill gpilz ram

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]