| Request Number: 758 | Date submitted: 24 May 1995 |
| Status: resolved | Date resolved: 24 Oct 1996 |
| Title: ndt_money key should be acronym | |
| Description: Appendix F for ndt money gives the reference to ref_currency_unit as being the name. It should reference ref_currency_unit.acronym. | |
| Resolution: This has been corrected in version 2.1 of the DAE specification. | |
| ------------------------------------------------------------------------------------------- | |
| Request Number: 916 | Date submitted: 16 Aug 1995 |
| Product: Data Access | |
| Status: resolved | Date resolved: 24 Oct 1996 |
| Title: What subtype am I? | |
| Description: Relationships are often given at a high
level. If I am given an instance, I often need to know which subtype the
instance is.
This information is obtainable from a Level 1 call. (Level 2? I don't know.) But more specifically, you may need to know the whole hierarchy from the top (where the relationship is defined) to the subtype of the instance. That is, you may also need a method that allows to move up the supertype hierarchy along the proper branch until you get to a level you understand. For example, I may have a relationship from a well to activity. I need to know which kind of activity (which subtype). I query using the Level 1 call, and find out it is "number_3_pullout", which is not understood (it is an extension.) But if I were to query up the supertype hierarchy, I might find out that it is a subtype of "install plug", which is an understood value. It is necessary that I be able to traverse until I reach the understood level. | |
| Resolution: We added the SQL3 TYPE predicate to the language specification for version 2.1. Although this does not completely address your issue, it is a starting point that is consistent with SQL3. We could not determine a reasonable language implementation for what you describe that did not go well beyond anything in SQL3. | |
| ------------------------------------------------------------------------------------------- | |
| Request Number: 926 | Date submitted: 05 Sep 1995 |
| Product: Data Access | |
| Status: resolved | Date resolved: 24 Oct 1996 |
| Title: Currency should reference the acronym | |
| Description: ref_currency presently has a name and an
acronym attribute. As instantiated, both the name and the acronym are given
and are unique.
Recommend that the spec reference the ref_currency_unit.acronym rather than the ref_currency_unit.name. | |
| Resolution: This has been corrected in version 2.1 of the DAE specification. | |
| ------------------------------------------------------------------------------------------- | |
| Request Number: 940 | Date submitted: 15 Sep 1995 |
| Product: Data Access | |
| Status: resolved | Date resolved: 24 Oct 1996 |
| Title: Relocate facility administration to new section | |
| Description: The facility administration specification in sub-section 4.13 should be moved to a new section dedicated to facility administration. | |
| Resolution: Facility administration has been moved to Section 13 in the DAE specification. | |
| ------------------------------------------------------------------------------------------- | |
| Request Number: 951 | Date submitted: 01 Oct 1995 |
| Product: Data Access | |
| Status: resolved | Date resolved: 05 Aug 1996 |
| Title: Need call to register server in static work environment | |
| Description: There is no call specified in the facility administration section to allow a server to be registered in the static work environment (i.e., there is no way to add an instance of dae_server to the static work environment). | |
| Resolution: The registration of servers in the static work environment is implementation defined. | |
| ----------------------------------------------------------------------- | |
| Request Number: 974 | Date submitted: 26 Oct 1995 |
| Product: Data Access | |
| Status: resolved | Date resolved: 24 Oct 1996 |
| Title: Frame Statistics terminology | |
| Description: The frame statistics utility returns a
histogram of the frame values. In the statistics information preceding
the histogram, it gives a TYPE: NORMAL_DISTRIBUTION. This term is
misleading.
The two values for TYPE are NORMAL_DISTRIBUTION, and LOGARITHMIC_DISTRIBUTION. A typical user would interpret those terms as stating that the data falls into a normal (gaussian) distribution or a log normal distribution. However, the meaning is totally different. The intended meaning is that the frequency bins are spaced linearly or logarithmically. I would suggest using the terms: LINEAR_SCALE, and LOGARITHMIC_SCALE for the TYPE. | |
| Resolution: This has been corrected in version 2.1 of the DAE specification. | |
| ----------------------------------------------------------------------- | |
| Request Number: 978 | Date submitted: 30 Oct 1995 |
| Product: Data Access | |
| Status: resolved | Date resolved: 24 Oct 1996 |
| Title: Clarify description of corner point grids | |
| Description: The description of corner point grids should be clarified by specifying that nodes of a cell are numbered clock-wise-right-handed from 1 to 8 with node 1 at the cell origin. | |
| Resolution: This has been done in version 2.1 of the DAE specification. | |
| ----------------------------------------------------------------------- | |
| Request Number: 980 | Date submitted: 31 Oct 1995 |
| Product: Epicentre Data Model | |
| Status: resolved | Date resolved: 24 Oct 1996 |
| Title: Formulas to define values in leaf frames | |
| Description: Add the capability of declaring a formula to define values in leaf frames of type DAE_C_FLOAT or DAE_C_DOUBLE. When a frame has a formula, values for arrays are automatically generated from the formula upon retrieval. Attempts to change the data by changing numbers in the arrays are ignored. This capability could be used as an alternative to storing geometry information in grid_1d_equal grids. | |
| Resolution: The functions daeSetLeafFormula and daeGetLeafFormula have been aded to provide the capability to define values in leaf frames of type DAE_C_FLOAT or DAE_C__DOUBLE. | |
| ----------------------------------------------------------------------- | |
| Request Number: 981 | Date submitted: 31 Oct 1995 |
| Product: Epicentre Data Model | |
| Status: resolved | Date resolved: 05 Aug 1996 |
| Title: Call to create a leaf frame and return its handle | |
| Description: Add a new call or modify the existing daeCreateLeafFrame call to create a leaf frame and return the handle of the new leaf frame. Since deaCreateLeafFrame does not return the handle of the leaf frame it creates, it must be followed by daeGetFrameChild to get the handle. | |
| Resolution: The new function daeCreateLeafFrameHandle has been added which creates a leaf frame and also returns the handle of the new leaf frame. | |
| ----------------------------------------------------------------------- | |
| Request Number: 988 | Date submitted: 01 Nov 1995 |
| Product: Data Access | |
| Status: resolved | Date resolved: 05 Aug 1996 |
| Title: Language function to return the type of an instance. | |
| Description: A language function is needed to return the type of instance (i.e., a language counterpart to daeGetEntityName). | |
| Resolution: It was decided to add a TYPE predicate instead of a function, as this is consistent with SQL3. | |
| ----------------------------------------------------------------------- | |
| Request Number: 996 | Date submitted: 01 Nov 1995 |
| Product: Data Access | |
| Status: resolved | Date resolved: 24 Oct 1996 |
| Title: Separate function prototype and data type definitions | |
| Description: dae.h should be split into two files separating the definitions of function prototypes and data types. A new file named daeTypes.h will contain the data type definitions. Only the function prototypes and error codes will be defined in dae.h which will include daeTypes.h. This change is motivated by IAC applications which must use the DAE data types but do not need to use the DAE functions. | |
| Resolution: This has been done in version 2.1 of the DAE specification. | |
| ----------------------------------------------------------------------- | |
| Request Number: 997 | Date submitted: 01 Nov 1995 |
| Product: Data Access | |
| Status: resolved | Date resolved: 05 Aug 1996 |
| Title: xpand discussion of date and time data types. | |
| Description: The discussion of date and time data types should be expanded to include additional aspects of their SQL3 specification. | |
| Resolution: This has been added to version 2.1 of the DAE specification. | |
| ----------------------------------------------------------------------- | |
| Request Number: 1025 | Date submitted: 01 Dec 1995 |
| Product: Epicentre Data Model | |
| Status: resolved | Date resolved: 24 Oct 1996 |
| Title: Enums conflict with MFC | |
| Description: In daeTypes.h, two keywords used in
enumerations conflict with enumerations used in MFC. Because MFC is a
common application development framework, this conflict greatly restricts
the use of compliant DAEF offerings, while offering no benefits in return.
Therefore, the conflict should be avoided by changing the conflicting enumerations:
| |
| Resolution: The DAE_ prefix has been added to the constants of the daePrivilege. | |
| Index of Problems/Changes | POSC Home Page |
Copyright © 1996 Petrotechnical Open Software
Corporation. All rights reserved.
POSC ® and the POSC logo ® are registered trademarks and Epicentre™
is a trademark of Petrotechnical Open Software Corporation.