Late binding and early binding characterizes different programming models in SDAI. Within STEP the term late and early is used to characterize at which point things get specific for a particular EXPRESS schema and entity types.
For early binding the EXPRESS model must be known at compile time. For every entity corresponding Java classes and interfaces are generated with access methods (get/set/unset/create) for every attribute of the entity and its supertypes. An example is the entity --product-- with attribute name. The corresponding Java interface EProduct and implementing Java class CProduct with access methods getName, setName and unsetName. Programming in early binding is the preferred ways for all translator applications since it is easy to use, allows effective programming, and many potential errors can be detected at compile time.
For late binding every kind of entity instance is represented by the Java interface EEntity. This interface defines a generic set of access methods get, set, unset, and create for every attribute. The specification of the attribute is given by an additional parameter. Late binding requires intensive use of the SDAI-dictionary schema. In general late binding is more complex and usually a bit slower than early binding. The main advantage is that the resulting application is not dependent of a specific EXPRESS schema. Example for late binding applications are SdaiTerm, SdaiEdit, Validate, and the generic STEP-Book.
First, you do not need to understand the sdai_dictionary_schema at all as long as you operate on early binding only. This is sufficient for practically all translator applications and much more. Only when you need to operate with late binding you need to get a basic understanding of this schema.
The sdai_dictionary_schema is a representation of EXPRESS on a meta level. The only way to create a population of this schema if by using the JSDAI Express Compiler. The main entity instances generated by the Express Compiler are:
There are further entities for every EXPRESS data-type such as aggregate, enumerations, defined_types and selects, and enumerations and much more. A complete EXPRESS schema in ASCII form can be re-generated from the meta information generated by the Express Compiler.
Sometimes yes, sometimes not.
Most of the Express schemas defined in STEP and PLIB are already included in the JSDAI-Library, which is delivered together with the JSDAI-Runtime. As long as you want your application to use only this library you don't need the Express Compiler.
However it may happen that you need some special extensions or modifications of the standardized Express schemas. Or you want to develop your own Express schema. In this case you need the Express Compiler.
If your Express schema is part of the STEP or PLIB standard, please inform us. We will include it in the next update of the JSDAI Express Compiler. Otherwise, or if you do not want to wait this long you need the JSDAI Express Compiler to compile the schema and make it available for the JSDAI-Runtime.
The JSDAI sources are not available publicly and the licensing conditions do not allow to disassemble the executable .jar, .class, and .exe files we deliver. However if you intend to use JSDAI in a bigger project, LKSoft can also offer you the sources for your specific usage or alternatively a escrow deposit.
No, JSDAI is a commercial product, which is directly based on several parts of the international STEP standard ISO 10303:
No. JSDAI, and all its components are commercial applications, copyrighted by LKSoftWare GmbH (LKSoft).
However LKSoft grants a free evaluation of the main components of JSDAI for 30 days. This includes the JSDAI Runtime, the JSDAI Library, the JSDAI Express Compiler and the JSDAI 3D Viewer. For details please look at the licensing conditions.
