SDAI (p22)

SDAI stands for Standard data access interface and is defined in ISO 10303-22. SDAI is not only an Application Programming Interface (API) to operate on application data, specified by an Express schema. SDAI specified how to organize application data in distributed environments, including validation, transaction control, and meta data.

Programming language bindings

SDAI is an abstract specification on how to deal with Express defined data and how to organize it. SDAI can be mapped to various programming languages and platforms:

  • Part 23 (IS): C++ language binding of the standard data access interface
  • Part 24 (IS): C language binding of the standard data access interface
  • Part 27 (TS): Java™ programming language binding to the standard data access interface with Internet/Intranet extensions. JSDAI is a full implementation of this.
  • Also a Fortran and Corba/IDL were developed but not finished.

Late and early binding

SDAI defines two ways how to access the attribute values of entity instances:

  • Late Binding: Here the name of the attribute is a parameter, either a string or an attribute instance from the SDAI dictionary. This allows developing applications for arbitrary Express schemas because the specific Express information is given as a parameter. The disadvantage is that no checking at compile time for specific Express constructs is possible.
  • Early Binding: Here the name of the attribute is part of the access functions/methods. This allows many compile time checks, ensuring the correctness of the application.

The Java binding to the SDAI (part 27) and the JSDAI implementation supports both early and late binding (based on SDAI dictionary) in parallel. Early binding allows a very efficient programming and is typically used for all kinds of converters. Late binding applications on the other hand are much more complex to develop but allow generic applications for arbitrary Express schemas. Examples for this are SdaiTerm, SdaiEdit and STEP-Book.

SDAI dictionary schema

The SDAI dictionary schema is a documentation of the structure of Express on a meta level. Every Express schema can be converted into a corresponding population of the SDAI dictionary schema and vice versa. The main purpose of the SDAI dictionary schema is to support late binding programming. The SDAI dictionary schema is not needed for early binding programming.

The main entities defined in the SDAI dictionary are:

  • schema_definition, representing an Express schema as a whole;
  • entity_definition, representing a single entity;
  • attribute representing an attribute of an entity with subtypes derived_attribute, explicit_attribute, and inverse_attribute.

In JSDAI the original SDAI_dictionary_schema was extended to cover every detail of an Express schema on the meta level. This includes:

  • interfaced Express elements from other schemas (USE FROM, REFERENCE FROM, implicit)
  • constants, expressions, functions, and procedures
  • view and map for EXPRESS-X
  • Express version 2 (Amendment)
  • comments

Application data

The main purpose of SDAI is to define operations to work with application data defined by an Express schema. For this SDAI defines some 30 operations for entity instances and their attributes and another 37 operations to work on aggregates and members of aggregates. These operations provide all needed functionality for reading, modifying, creating and validating any kind of application data.

Organizational objects

SDAI is much more than an API to work on Express defined data. The extended functionality is provided by the organizational objects and the dictionary_schema.

  • sdai_session to wrap up all information when working with SDAI;
  • implementation, providing details of the actial SDAI implementation;
  • sdai_transaction, controlling committ and abort operations;
  • sdai_repository, as the physical place to store entity instances
  • sdai_model, for logical grouping of entity instances;
  • schema_instance, to define formal collections of sdai_models, suitable for validation purposes.

Besides accessing all the attributes of the organizational objects mentioned above in read only mode, SDAI defines some 50 (write) operations for these objects changing the state of SDAI. These operations make up the power of SDAI, making SDAI much more than an API to operate on entity instances and attributes.

Implementation Classes

Like other STEP standard formal conformance testing is an important part of SDAI. Since SDAI provides a big functionality, different levels of implementation are defined for different categories:

  • Levels of transaction
    • Level 1 is reserved for low end implementations with no kind of transaction support.
    • Level 2 is a simple transaction mechanism on sdai_model basis only with save and undo operations.
    • Level 3 is full transaction support for the whole sdai_session with commit and abort operations. This is the basis for JSDAI
  • Levels of expression evaluation for validation and derived attributes. Four levels of increasing expression support are defined, from no support (level 1) to full validation support (level4). JSDAI is supporting level 4.
  • Levels of session event recording support. During the execution of SDAI operations errors can happen due to several reasons. Traditionally there are two ways how to deal with them, either to check after each operation the error state or to record possible errors and check them afterwards. The Java binding and thus JSDAI chooses a third approach. In case of an abnormal situation an exception is thrown. This feature of Java is much more powerful that the old styles and leads to more robust programs.
  • Levels of scope support. Scope is a deprecated feature in all STEP implementation methods. It is not supported by JSDAI.
  • Levels of domain equivalence support. The question here is if Express short form schemas (level 2) or only long form schemas (level 1) are supported. With its superior Express short form support JSDAI clearly goes for level 2.

SDAI groups the various levels and categories into 7 implementation classes, 1 with the lowest level and 7 for complete SDAI support. JSDAI conformas to implementation class 7.

Part 35, the ''Abstract test methods for standard data access interface implementations" defines specific test cases for all the implementation levels and classes. JSDAI has passed all of them.