3 SDAI Library Changes

3.1 Changes from 9.0 to 10, and 11

Except for bug fixes, there have been no changes to the SDAI library API functions past the ST-Developer v9 release.

3.2 Changes from 8.0 to 9.0

In ST-Developer v9, the SDAI interface incorporates several changes. In general, these changes add functionality and fix bugs. Code which works against the v8 interface will continue to function without any source code changes. The additional functionality is in the form of a low-level interface which provides a cleaner interface with the ROSE library.

If you decide to recompile your existing code to take advantage of the new features in the SDAI library, you should recompile the entire project to avoid unpleasant surprises at link or run time.

Part 24 IS Conformance

Part 24 has recently been published as an International Standard by ISO. The SDAI library conforms to this specification. You will not need to change your code to conform this specification.

The IS standard specifies that the non-persistent lists created by retrieving the value of INTERSE attributes are now only guaranteed until the next call that retrieves an inverse attribute. This means that applications no longer need to call sdaiDeleteNPL() to release the NPL. This automatic deletion has not yet been implemented in the ST-Developer version 9 release, so you should continue to manually delete the NPL, or else your application will experience a memory leak. We do plan to implement this feature in a future release.

Low-Level Interface

For many applications, the higher-level, application management portion of the SDAI only adds complexity to the application without adding any real value. For this reason, the Version 9 release of the SDAI library provides a low-level interface in which you avoid the sdaiOpenSession() / sdaiOpenRepository() / sdaiAccessModel() calls, and instead use to ROSE library to access a design, then directly manipulate the data.

This new functionality enables SDAI applications to access and manipulate Part 21 files with multiple data sections, as well as making it easier to write utility functions. For more information, see Low-Level Model API.

Other changes

This release of the SDAI adds support for multiple schemas. It is now possible to manipulate Part 21 exchange files without resorting to the ROSE interface. See Multiple Schemas for more information.

The library now has a several convenience functions that efficiently perform queries against the data dictionary. These functions provide a convenient, and fast method to get the full set of attributes (local and inherited), determine all the super and subtypes of an entity in a schema, and to get all the uniqueness rules that apply to in entity. These functions are _sdaiGetAllAttrDefinitions (), _sdaiGetDerivedAttrDefinitions(), _sdaiGetExplcitAttrDefinitions(), _sdaiGetInverseAttrDefinitions(), _sdaiGetSubtypes(); _sdaiGetSupertypes(), and _sdaiGetUniquenessDefinitions().

This library now has a new _sdaiSaveAs() function. See _sdaiSaveAs() for more information.

A bug that causes the application to crash if it open, closes and reopens a session has been corrected.

A bug caused the library to crash with null-pointer access when reading the EXPRESS parse data for a schema that has a defined type whose underlying type is an aggregate has been corrected.

3.3 Changes from 7.0 to 8.0

ST-Developer Version 8 includes a number of improvements in the SDAI C binding. In addition to a few bug fixes, the SDAI library now provides a more convenient interface for manipulating SELECT types, and a few extension functions for handling Part 21 headers and entity ID's.

Recompile EXPRESS Parse Data

Due to changes in the EXPRESS compiler, you will need to recompile any parse data files (e.g. *_EXPX.rose ) you are using. If the system encounters old parse data, it generates the message:

    WARNING: Old version of parse data: file_EXPX.  Ignoring it.

and uses does not extend the dictionary data beyond the information contained in the ROSE schema file. This means the EXPRESS interpreter, INVERSE attributes, and rule checking will not function until you recompile the EXPRESS file with the command:

    expfront schema.exp

All the parse data for information models included with ST-Developer has been recompiled. You only need to recompile you own EXPRESS schemas.

Updating SELECT Attributes

The sdaiPutAttr() and sdaiPutAttrBN() functions are now more forgiving when operating on SELECT typed attributes. In previous releases, you needed to specify a path through the tree of selects which specified every defined type that was involved. In the new version, these rules have been significantly relaxed. If the value you are setting is an ENTITY type, you do not need to indicate a type path at all, rather the system will find and utilize an appropriate path. In the case of primitives, you still need to provide a type path, but you only need to specify enough of the type path to identify the attribute.

See SELECTS form more information.

New models created in STEP format

When you create a new SDAI model with sdaiCreateModel() , the model will be written out as a STEP Part 21 file by default. In previous versions, the file was written out as a rose file. If you want to write a file in binary format, call

     _sdaiSetModelFormat(model, "standard").

This change only effect newly created files; any model that was read in from a file is written out in the same format that is was read in. This change only effects the SDAI, and not the ROSE library.

Part 21 File Accessor functions

The SDAI library now contains a few conveniences functions the access and manipulate the STEP Part 21 information. The _sdaiGetEntityId() function returns the STEP Entity ID (e.g. line number) from a step file.

    int id = _sdaiGetEntityId (inst);

In addition, the SDAI now contains the _sdaiHeaderDescription() and _sdaiHeaderName() functions to manipulate the Part 21 header information.

Other Changes

In the 7.0 version of the SDAI library, a number of aggregate manipulation functions (such as sdaiAdd() ) did not correctly operate, and instead indicated an errors for what should be legal operations. This bug has been corrected.

A bug in the 7.0 version of the SDAI library where sdaiTestAggrByIndex() and released functions always returned true has been fixed.

Past versions of the SDAI library generated names of entity_definition instances for complex types incorrectly. The new version now correctly generates the names as defined in Part 22, with the supertypes (sorted alphabetically) separated by the ` + ' character.

In addition, we have improved the speed of the sdaiGetAttr() function.

We have cleaned up the namespace so that the SDIA library exports no functions except those that begin with sdai or _sdai . You may still notice some namespace pollution, but there is now nothing beyond what the ROSE library provides.

3.4 Changes from 1.6 to 7.0

We have made several changes and improvements to the current SDAI library since the ST-Developer 1.6 release. Due to these changes, the current version is now installed as the default SDAI library. It now features validation functions, schema instance support, an extended interface to the ROSE-level data structures, an interface to the advanced EXPRESS interpreter, and a number of bug fixes.

The SDAI dictionary is now generated at run-time, thus the express2sdai_dis utility has been eliminated from the release. When a model is loaded into memory (with sdaiAccessModel() , or related functions), the SDAI generates a dictionary based on the model's ROSE schema. It then, completes the dictionary to include the types attribute and rules in the advanced EXPRESS compiler parse data.

The library now includes an optional interface to an EXRESS interpreter. The interpreter can be used to get the values of derived attributes, and to validate where and global rules defined in the EXPRESS information model. A number of validation function which do not require the EXPRESS interpreter are also now implemented.

This release of the SDAI library supports schema instances. A schema instance is a set of models which are related in some application-defined way. A model may belong to more than on schema instance. Schema instances are used to identify the set of data over which global and uniqueness rules are evaluated.

This interface better conforms to Part 24 and Part 22. Attribute of all types, including REAL and INTEGER can be unset with the sdaiUnsetAttr() function. The aggregate access functions (e.g sdaiGetAggrByIndex() , etc.) are now stricter in validating their parameters for the correct aggregate type.

The functions which provide the interface between the ROSE library have been extended, to allow applications to mix the ROSE and the SDAI API's. We have also added a new feature property feature by which an application can easily associate data with an SDAI instance.

New Library Names

The current version of the SDAI library is now installed as the default version of the SDAI. When you compile an SDAI application you should use the sdai.h header file in $ROSE_INCLUDE . (The old $ROSE_INCLUDE/sdaidis include directory has been removed from the release.) The SDAI library has been similarly renamed from -lsdaidis or sdaidis.lib to -lsdai or sdai.lib .

The old CD version, which used to be the default, is still available. If you wish to use the old version add $ROSE_INCLUDE/sdaicd to your include path, and link against -lsdaicd or sdaicd.lib .

Dictionary Generation

The SDAI dictionary is now generated at run-time. When a model is accessed, the ROSE library loads the corresponding schema file; the SDAI library then generates the dictionary for the schema. If an EXPRESS parse data file can be located, the SDAI library uses it to generate a complete dictionary for the schema.

Due the this run-time schema generation the express2sdai_dis utility is no longer required, and has been removed from the release. You should now use the advanced EXPRESS compile, expxfront , to generate the EXPRESS parse data files instead.

At times, an application may wish to directly access the dictionary without loading a model based on the schema. In previous releases, an application was required to explicitly load the dictionary model with code like:

    dict = sdaiAccessModelBN(reop, "config_control_design_SDAI_DICT", sdaiRO);

This no longer works in the new release. Instead, you should use the sdaiGetSchema() function instead. This function causes the dictionary to be generated in the same way as when a model is loaded.

See The SDAI Dictionary for more information about how the data dictionary is now from the ROSE schema and EXPRESS parse data.

EXPRESS Interpreter

The SDAI library now contains an interface to the advanced EXPRESS interpreter. The interpreter is used to validate global and where rules, and to calculate the values of derived attributes. The release includes two versions of the SDAI library -- one with the interpreter, and one without it. You must link against the version with the interpreter before using any on the features described in this section. See Compiling SDAI Applications for more information about compiling SDAI applications with the EXPRESS interpreter.

In addition to linking with the correct version of the libraries, you must have the full dictionary (and EXPRESS parse data) available at run-time to utilize the interpreter.

The EXPRESS interpreter is used to calculate derived attributes by the sdaiGetAttr() and sdaiGetAttrBN() functions. In addition to getting the values of derived attributes, the EXPRESS interpreter is also used to validate global and where rules by the following functions:

Schema Instances

Schema instances are now supported by the SDAI library. While previous versions had a minimal, stub versions of schema instances available, the new version fully supports the required operations of schema instances. See Schema Instances for more information.

Validation

The SDAI library now supports a number of validation functions. These functions check if a portion of a data set conforms to the constrains defined in the EXPRESS information model. All of the validation functions require that the complete dictionary be generated (e.g. the EXPRESS parse data must be loaded), and several functions -- sdaiValidateGlobalRule() , sdaiValidateGlobalRuleBN() , sdaiValidateWhereRule() , and sdaiValidateWhereRuleBN() --also require that the you link against the library with the EXPRESS interpreter.

The validation functions are the following:

Strong Type Checking for Aggregates

The aggregate access functions now validate the types of their parameters. In the past release any type of aggregate, as long as it was an attribute of a application instance, could be used as a parameter for any aggregate access function. In this release, the correct function must be used or an error, usually sdaiAI_NVLD , is generated.

The following functions require the aggregate parameter to be an unordered aggregate (e.g. bag or set)

The following functions require the aggregate parameter to be an ordered aggregate (e.g. array or list)

The following functions require the aggregate parameter to be an array.

The following functions require the aggregate parameter to be a list:

Unset Attribute Values

The SDAI library now supports unset value for all types. Past releases did not support unset values for integer and real number types. The sdaiUnsetAttr() function now correctly removes the value from any attribute. It you try to access an unset attribute, the SDAI generates an sdaiAT_NDEF error.

ROSE Access Functions

This release of the SDAI adds a number of functions that assist in interfacing with the underlying ROSE library. The ROSE library provides low-level data management functionality for the SDAI, and sometimes an SDAI application need to directly call ROSE methods. The _sdaiGetRoseDesign() , and _sdaiGetModel() functions convert between RoseDesigns and SDAI models. The _sdaiGetEntityForDomain() and _sdaiGetDomainForEntity() functions convert between ROSE and SDAI meta-data. See Interfacing with ROSE for more information.

3.5 Property Functions

This release of the SDAI library contains a set of extension function which allow you to associate application-specific data with an application instance. A property is implemented as a void* that is associated with an instance. By using properties, an SDAI application can avoid using lookup tables or other data structures to associate additional, data with a specific instance.

For more information about using this feature, see Property Functions. The API functions which implement properties are _sdaiGetProp(); _sdaiGetPropType(); _sdaiRemoveProp(); and _sdaiSetProp().

New Functions

The following functions have been added to the SDAI library for the ST-Developer Version 7 release.

Corrected Bugs

A number of bugs and other problems in the ST-Developer 1.6 version of the SDAI library have been corrected:

A severe memory leak in the Non-Persistent Lists (NPLs) has been fixed.
Dictionary instances are now created with the correct lower-case names.
The _sdaiGetAllAttrDefinitions() function did not correctly return inherited attributes. This problem has been corrected
Redeclared attribute are handled correctly in the library. There was a bug in the ST-Developer 1.6 release which could make a the contents of a model inaccessible if the schema contained redeclared attributes
You may pass a full path name to sdaiAccessModel() . Previous releases contained a bug that required the application specify the model name as it was stored in the repository.
The attributes member of entity_definition in the dictionary now works correctly. This is an inverse attribute, which was incorrectly defined in the dictionary for the SDAI dictionary model.
Complex entities are created and initialized when a model is loaded, rather than on demand. This allows you to browse the dictionary to find the complex types in the ROSE working set.

SDAI C Reference 3 SDAI Library Changes