Issue 3753: current_version()
Issue 3782: The parent input parameter in the get_xxx calls only take one ResourceID
Issue 3802: What would a URI for an enumerated value look like
Issue 3909: Issue with inverse properties
Issue 3753: current_version() (daf_ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: By way of background, our DAF implementation is based on J2EE and Enterprise Java Beans stored in an Oracle database. Our data provider will be transactional. I'm a little unclear on what the integer value for current_version() needs to return. Section 5. Events says that a version number is a unique integer assigned to each data change. A data provider may issue either general or specific data change events, depending on circumstances.
The way I'm reading this, any time that any of the data served up by the data provider changes the version gets incremented. Is this correct? Or are there extenuating circumstances that affect the version numbering??
If the data provider is serving up data based on data changes that are coming in via messages, won't the version number be changing a lot?
Resolution:
Revised Text: 2.1.2 Recommendation
The recommended solution is to separate the event reporting and the concurrency conflict detection as follows:
· Event reporting will only be available via the CosEvent-based interfaces. It will not be possible to poll current_version() to reliably detect a change.
· The contract of the current_version() method can then be modified to provide a inconsistent read detection required by data providers of type (2) above without affecting data providers of type (1) or (3).
· No change is recommended to support fine-grained events. Events remain on a per-class or global basis, which is in accordance with the RFP requirements. A future specification, perhaps using CORBA Notification or other event technology could deal with fine-grained events and their subscription criteria.
The following changes are recommended, as per [1]:
· The ResourceChangeEvent::version field is removed. (Section 5.)
· The contract of current_version() is changed so that a data provider of type (1) or (3) can effectively opt-out of the protocol and implementation is easier for a data provider of type (2).
· The return type of current_version() is changed to unsigned long long so that time stamps can be used for versions if desired.
· The discussion is changed accordingly. (Section 5.2.)
· The behaviour of proxy data providers is changed (Section 7.4.)
Page numbers affected: 37, 38, 39, 40, 42, 43, 49.
Actions taken:
July 20, 2000: received issue
May 24, 2001: closed issue
Discussion: The provision in the event specification that associates version numbers with updates to the server's state is undesirable. These version numbers are conveyed to the client by the current_version() operation as well as via events. The original motivation for this was twofold:
· Provide a means for an application, such as a State Estimator, to poll for changes in the model. This is an alternative to listening to the event interface.
· Determine if a model change took place during the reading/navigating process, thus indicating that the data read might be inconsistent.
The version number approach creates a bottlneck for transactional systems, as every transaction must contend for the current version datum. And it is not easy to implement in non-transactional systems, as each change must be intercepted and cause the current version to be incremented. Furthermore, it is not clear what value should be returned by a data provider that enters a long-lasting, inconsistent state.
An improved solution needs to accommodate three types of data provider:
1. Transactional data providers e.g. based on Oracle. These should be able to opt out of the version protocol. A DAF interface wrapping an Oracle system could offer full CORBA transaction support.
2. Non-transactional data providers. This is a large class of potential implementations including implementations that wrap the real-time portion of a typical EMS system. For these, some protocol is required to detect infrequent model changes that collide with model access. If a collision is occasionally detected the client can retry its query sequence.
3. Real-time data providers. This type of data provider will update frequently, but in such a way that clients never see inconsistent data. For example, individual voltage values may change constantly but clients need not be concerned about moderate time skew as they acquire a set of voltage values. Neither transaction support nor the version protocol is required.
A client must work unchanged with any of the foregoing kinds of data provider.
Issue 3782: The parent input parameter in the get_xxx calls only take one ResourceID (daf_ftf)
Click here for this issue's archive.
Source: ABB Power Technologies, Power Automation & Substat (Mr. Lars-Ola Osterlund, lars-ola.g.osterlund(at)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?
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.
What would a URI for an enumerated value look like? Also, maybe you could answer another question: If you wanted to determine a property's domain, range, etc., what DAF method would you use?
Clarification of the representation of enumerated values in RDF and hence the DAF interfaces was requested by SISCO systems. SISCO and CIM-Logic asked for clarification of the handling of null values. Similarly, SISCO asked for clarification on how schema queries would be made. Issue No. 3802. 2.5.1 Discussion An enumeration is represented in the CIM schema as a Class and the enumerated values as resources belonging to that class. Each CIM enumerated value is designated by a URI-reference within the CIM namespace. A null value is represented as the absence of a statement. That is, the absence of a property and value in a ResourceDescription is equivalent to a null value in a relational database field.
Issue:
in the past we have seen a question about how to find all the properties of a given class. That operation requires a special schema property to be defined which is the inverse of the rdfs:domain property. In other words, to do this operation in a standard way we need to extend the RDF schema.
This problem is likely to arise again where ever we have a property with no inverse defined. For example, finding all the properties that refer to a given class requires an inverse to rdfs:domain. Navigating the CIM is fine because we have defined inverses for all properties, but it seems unreasonable to expect this of every schema that might be used with the DAF.
Proposed Solution:
The DAF interface should support inverse navigation for any resource-valued property. Informally, it should be possible make queries of the form: "What resources have a property P with value V?" The value V is restricted to be a resource.
One solution is to add new query methods to the ResourceQueryService interface. However, that represents a considerable expansion of the IDL. The proposed solution has much less impact and is more general.
A boolean member called "inverse" should be added to the Association structure, thus:
struct Association
{
PropertyID property;
ClassID type;
boolean inverse;
};
Wheninverse is false, the association is interpreted as per the current specification. When inverse is true the the association is interpreted as if the inverse of the given property were supplied. In either case the type member retricts the resources resulting from the query to the given class.
More formal wording for the specification is required, of course.
Regards,
Arnold
Some implementers asked how to find all the properties of a given class. Although this is a fundamental operation, it requires a special schema property to be defined which is the inverse of the rdfs:domain property. In other words, to do this operation in a standard way we need to extend the RDF schema. Issue No. 3909. 2.4.1 Discussion It is often necessary to query all resources for which a given property has a given value. Finding all Property's with a given domain Class is a special case of this query. Such a query can only be made if the schema defines an inverse of the given property. This is an unreasonable restriction in the API since there is no requirement that RDF schema should define inverses of all properties. Therefore the interface should support inverse navigation for any resource-valued property. It should be possible make queries of the form: "Which resources have a property P with value V?" where value V is a resource. One solution would be the addition of new query methods to the ResourceQueryService interface. However, that represents a considerable expansion of the IDL. The proposed solution has much less impact and is more general.