This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Description: WS-Management v1.1 [1] Section 8.2.2 defines an extension to WS-Enumeration wherein a consumer is provided with an estimate of the number of items in an enumeration. This allows consumers to allocate the resources necessary to store and process the results of the ensuing Pull operations in a more efficient manner than what might be possible with a pull/store/resize/copy pattern. It is the opinion of the WS-Man WG that this feature is sufficiently general as to warrant inclusion in the base specification. The WS-Man WG requests that WS-RA WG incorporate this extension as an optional feature of WS-Enumeration. [1] http://www.dmtf.org/standards/published_documents/DSP0226_1.1.pdf --- Proposal: Although WS-Management applies this extension to both the wsen:Enumerate and wsen:Pull operations, this proposal narrows the application to an option of the wsen:Enumerate/wsen:EnumerateResponse exchange. 1. Modify the Enumerate request to include an optional element or define a soap header that is equivalent to wsman:RequestTotalItemsCountEstimate. 2. Modify the EnumerateResponse message to include an element or header that is equivalent to wsman:TotalItemsCountEstimate. 3. Define an additional fault to cover the case where a consumer requests the enumeration count from a data source that does not support this feature. 4. Add a parameter to the wsenu:DataSource assertion to indicate that an endpoint supports the Count feature. 5. Define a mechanism to allow a client to specify whether the request should be performed with or without the use of this feature in a way similar to the way mustUnderstand works.
Proposed Response to originator of bug 9607 The WS-RA WG considered your last call comment 9607 "Enum: Support WS-Management's Enumerate Count feature". After discussion, we agreed to close this issue with no change to the spec. The rational for this decision was that the cost in terms of spec and implementation complexity outweighs the potential benefits of saving a round trip of network exchange for a minority of use cases.
Sorry, there is a typo in the preceding comment. "9207" should be replaced with "9208" in the preceding comment.
To add to Tom's comment, after a discussion within the WG, 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.
Reviewer Satisfied http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0056.html