RE: [Bug 8306] New: description of Pull contains unclear sections

I like to propose the following:


*       Remove the paragraph [1] in "Pull" section.

*       Augment [2] existing description for "MaxTime".

Thanks.

[1] http://www.w3.org/2002/ws/ra/edcopies/wsenum.html#Pull

Upon receipt of a Pull request message, the data source MAY wait as long as it deems necessary (but not longer than the value of the wsen:MaxTime element, if present) to produce a message for delivery to the consumer. The data source MUST recognize the wsen:MaxTime element and return a wsen:TimedOut fault if no elements are available prior to the request message's deadline. Note, however, that this fault SHOULD NOT cause the enumeration context to become invalid (of course, the data source MAY invalidate the enumeration context for other reasons). That is, the requestor can issue additional Pull requests using this enumeration context after receiving this fault.

[2] http://www.w3.org/2002/ws/ra/edcopies/wsenum.html#Pull [Changes shown in red color below]

[Body]/wsen:Pull/wsen:MaxTime
This OPTIONAL element (of type xs:duration) indicates the maximum amount of time the initiator requestor is willing to allow the data source to assemble the Pull response. When this element is absent, the data source is NOT REQUIRED to limit the amount of time it takes to assemble the Pull response. The data source MUST recognize the wsen:MaxTime element and return a wsen:TimedOut fault if no elements are available prior to the request message's deadline. However, this fault MUST NOT cause the enumeration context to become invalid and the requestor can issue additional Pull requests using this enumeration context after receiving this fault.

-----Original Message-----
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Ram Jeyaraman
Sent: Wednesday, January 27, 2010 3:41 PM
To: public-ws-resource-access@w3.org
Subject: RE: [Bug 8306] New: description of Pull contains unclear sections



One of the reasons the a data source may need time to respond is because it may not host the data locally, it might be fronting some other service. The specification could clarify this.



-----Original Message-----

From: public-ws-resource-access-notifications-request@w3.org [mailto:public-ws-resource-access-notifications-request@w3.org] On Behalf Of bugzilla@wiggum.w3.org

Sent: Friday, November 13, 2009 8:07 PM

To: public-ws-resource-access-notifications@w3.org

Subject: [Bug 8306] New: description of Pull contains unclear sections



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



           Summary: description of Pull contains unclear sections

           Product: WS-Resource Access

           Version: PR

          Platform: All

        OS/Version: All

            Status: NEW

          Severity: normal

          Priority: P2

         Component: Enumeration

        AssignedTo: public-ws-resource-access-notifications@w3.org

        ReportedBy: gilbert.pilz@oracle.com

         QAContact: public-ws-resource-access-notifications@w3.org





The description of Pull contains the following paragraph:



"Upon receipt of a Pull request message, the data source MAY wait as long as it deems necessary (but not longer than the value of the wsen:MaxTime element, if

present) to produce a message for delivery to the consumer. The data source MUST recognize the wsen:MaxTime element and return a wsen:TimedOut fault if no elements are available prior to the request message's deadline. Note, however, that this fault SHOULD NOT cause the enumeration context to become invalid (of course, the data source MAY invalidate the enumeration context for other reasons). That is, the requestor can issue additional Pull requests using this enumeration context after receiving this fault."



It's not clear why the data source would wait, etc.



General Proposal: reword for clarity





--

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email

------- You are receiving this mail because: ------- You are the QA contact for the bug.

You are the assignee for the bug.

Received on Friday, 19 February 2010 23:04:42 UTC