Issue 3782: The parent input parameter in the get_xxx calls only take one ResourceID (daf_ftf) Source: ABB Power Technologies, Power Automation & Substat (Mr. Lars-Ola Osterlund, lars-ola.g.osterlund@se.abb.com) Nature: Uncategorized Issue Severity: Summary: The parent input parameter in the get_xxx calls only take one ResourceID. A client may not want to retrive a large data set in one call (e.g. using get_descendent_values) originating from one parent but instead divide the call in several and make some intermediate processing/filtering. In this case the client will most likley have an intermediate sequence of ResourceIds where each ResourceID will be a parent in subsequent get_xxx calls resulting in as many get_xxx calls as there are ResourceIDs. In this case it will be more efficient to to allow a sequence of parents in the get_xxx calls. What do you think? Resolution: Revised Text: The following changes are recommended, as per [1]: · The type of the parent argument of ResourceQueryService::get_descendent_values() should be changed from ResourceID to ResourceIDSequence. (Section 4.3.) Page numbers affected: 25, 26, 27, 28. Actions taken: August 14, 2000: received issue May 24, 2001: closed issue Discussion: One implementer, ABB, raised an issue with the signature of the ResourceQueryService methods. The parent argument in the get_xxx_values() operations in ResourceQueryService is a single ResourceID. However, there are scenarios in which it would be more efficient if this argument were a sequence of ResourceID's. Issue No. 3782. 2.2.1 Discussion A client may want to divide a single call to get_decendent_values() into several steps to permit filtering and to obtain intermediate results. At each intermediate step, the intermediate result is a ResourceID sequence. This sequence will be passed back to get_decendent_values() in the next step. However, this may be slower than necessary because get_decendent_values() must be called iteratively, once for each ResourceID. The proposal is to change the type of the parent argument in one or more ResourceQueryService operations from ResourceID to ResourceIDSequence. This fits the design rationale of the get_descendent_values() operation which is intended to be a generalised query. It is not appropriate for the get_values(), get_extent_values(), and get_child_values() operations where the goal is simplicity. In get_descendent_values(), the change would tend to round-out and strengthen the operation's originally intended role as the most general query. With this change, all of the arguments to this operation become sequences. End of Annotations:=====