This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11990 - Enum: MaxTime on create is problematic
Summary: Enum: MaxTime on create is problematic
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Enumeration (show other bugs)
Version: CR
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: notifications mailing list for WS Resource Access
QA Contact: notifications mailing list for WS Resource Access
Keywords: hasProposal
Depends on:
Reported: 2011-02-06 13:06 UTC by Doug Davis
Modified: 2011-09-13 21:34 UTC (History)
0 users

See Also:

from nathan (334.00 KB, application/msword)
2011-02-15 18:57 UTC, Doug Davis
minor tweak to nathan's proposal (333.50 KB, application/msword)
2011-02-15 19:04 UTC, Doug Davis

Description Doug Davis 2011-02-06 13:06:58 UTC
Enum has this text for the MaxTime element:
- - - - -
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 consumer can issue additional Enumerate requests using this enumeration context after receiving this fault. 
- - - - -

This is problematic due to the Pull() and Enumerate() now being
part of the same operation.  If the MaxTime is hit is during the
Enumerate/Create step a fault is thrown - this means that the client
will never get back the EnumerationContext for the new enum (which is still 
active). They would have no choice but to create an entirely new Enum - which
may not be what they want - and it means we have zombie enums left around.

- Modify Enum so that when MaxTime is hit the data source just returns
  zero Items in the response instead of a fault.
- remove the TimedOut fault
- modify the xsd so that Items can be empty
Comment 1 Robert Freund 2011-02-15 17:48:20 UTC
sense of the meting was that an explicit attribute indicating the ending timeout might be better
Comment 2 Doug Davis 2011-02-15 18:57:10 UTC
Created attachment 957 [details]
from nathan
Comment 3 Doug Davis 2011-02-15 19:04:12 UTC
Created attachment 958 [details]
minor tweak to nathan's proposal
Comment 4 Robert Freund 2011-02-15 19:06:12 UTC
Resolved as proposed in comment 3