<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Lothar Klein">
<meta name="GENERATOR" content="Mozilla/4.75 [en] (Windows NT 5.0; U) [Netscape]">
<title>Mapping Table Schema</title>
</head>
<body>
<div align=right><b>ISO TC184/SC4/WG11/N191</b>
<br>Date: 2001-01-31
<br>supersseds ISO TC184/SC4/WG11/N068</div>
<center>
<h1>
SDAI-2</h1></center>
<center>
<h1>
Requirements for the second edition of SDAI</h1></center>
<center><a href="mailto:lothar.klein@lksoft.com">Lothar Klein (lothar.klein@lksoft.com)</a>
<br><a href="mailto:vaidas.nargelas@lksoft.lt">Vaidas Nargelas (vaidas.nargelas@lksoft.lt)</a>
<br><a href="http://www.lksoft.com">LKSoftWare GmbH (http://www.lksoft.com)</a></center>
<hr>
<h2>
Contents</h2>
<a href="#Introduction">Introduction</a>
<br><a href="#SDAI_dictionary_schema">SDAI_dictionary_schema</a>
<br> <a href="#Data_types">Data-types</a>
<br> <a href="#sub_super">Sub-supertype restrictions:
ONEOF, AND, ANDOR</a>
<br> <a href="#short_form">EXPRESS short forms</a>
<br> <a href="#functions_expressions">Functions &
Expressions</a>
<br> <a href="#mapping_tables">Mapping Tables</a>
<br> <a href="#dictionary_as_application">Use Dictionary
Entites like Application Entities</a>
<br><a href="#sdai_repository">SDAI Repository</a>
<br> <a href="#import_export">Import and export of exchange
files</a>
<br> <a href="#repository_attributes">Additional attributes</a>
<br> <a href="#create_delete">Creating, deletion, temporarily
repositories</a>
<br> <a href="#remote_repository">Remote repositories</a>
<br> <a href="#copy_sdai_model">Copying an SDAI model</a>
<br> <a href="#usage_of_sdai_models">Usage of SDAI models</a>
<br><a href="#diverse">Diverse</a>
<br> <a href="#exception">Exception mechanisms</a>
<br> <a href="#entity_extent">Improving the organization
of entity instances</a>
<br> <a href="#base_entity">Application Entity instead
of Application Instance</a>
<br> <a href="#scope">No Scope</a>
<h2>
<a NAME="Introduction"></a>Introduction</h2>
ISO 10303-22:1998 is the first version of the Standard Data Access Interface,
we will call it SDAI-1 within this document. It is an abstract Application
Programming Interface (API) for arbitrary programming languages. The following
concreate (= non-abstract) bindings for programming language are defined:
<ul>
<li>
ISO 10303-23:2000 for the C++ binding</li>
<li>
ISO 10303-24:2001 for the C binding</li>
<li>
ISO/TS 10303-27:2000 for the (complete) Java(TM) binding</li>
</ul>
Other SDAI based standardisation activities:
<ul>
<li>
The planned Fortran binding has been canceled.</li>
<li>
The IDL/Corba binding which sucessfully passes the CD ballot has been canceled
due to lack of activities.</li>
<li>
The lightweight Java binding (ISO/CD 10303-29) did not progress for the
last 2 years.</li>
<li>
The "Abstract Test Methods for SDAI Implementations" is under work. It
has sucessfully passed its CD ballot in October 2001.</li>
</ul>
Commerial SDAI implementations are available from (source PDES.Inc website)
<ul>
<li>
Bentley (Microstation)</li>
<li>
EPM Technologies (ST-Developer)</li>
<li>
LKSoft (JSDAI)</li>
<li>
ProSTEP (IDA CaseLib)</li>
<li>
Softlab (GEP)</li>
<li>
StepTools (ST-Developer)</li>
</ul>
Furtheron several academic SDAI implementations where developed over the
last ~8 years, however it is not known if those implementations are still
available. It may also be noted here, that several STEP implementations
uses toolkits, that are not (directly) based on SDAI.
<p>The Goal of this document is to prepare for a Preliminary New Work Item
(PNWI) for the 2nd edition of SDAI (ISO 10303-22), covering also the ISO
TC184/SC4 Resolution 521 "Review of Impact of Express Edition 2".
<h2>
Requirements</h2>
The top requirements are to harmonise and extend with EXPRESS-X, EXPRESS-Amendment,
extend the scope and explicit support of part21 and 28. Several of these
requirements are already addressed in part 27.
<h3>
EXPRESS Edition 2 (Amenmend) support</h3>
The actual document for the 2nd version of EXPRESS (called the EXPRESS
Amenment) has several new features to be supported by SDAI:
<ul>
<li>
extensible selects</li>
<li>
extensible enumerations</li>
<li>
total-over</li>
<li>
separte subtype constraints</li>
</ul>
<h3>
EXPRESS-X and expression support</h3>
Already in SDAI-1 it was possible to access derived attributes of entity
intances, which are e.g. defined by EXPRESS functions and further on by
procedures. While doing this, new Entity instances and other datatype occurances
may have been created. SDAI-1 does not specify any domain, SDAI-repository
or SDAI-model in which this data is created. In EXPRESS it is defined that
this data is not persistent, it is only temporay available. Any detail
is left open.
<p>On the other hand the E-X construct MAP does explicitly create a new
"target population" and gives also guidelines how to convert VIEWs into
entity instances.
<p>The requirements is to extend SDAI for
<ul>
<li>
Operations to execute EXPRESS functions and procedures</li>
<li>
Specifying a domain (SdaiModel) in which new entity instances are created
during executing of derived attributes.</li>
<li>
extending the SDAI_dictionary_schema for generic data types, used in procedure
and functions</li>
<li>
Adding new operations to execute E-X <b>schema-map</b> and <b>map</b></li>
<li>
Extend the SDAI_parameter_data_schema for instances of E-X views</li>
<li>
Add operations to create view instance</li>
</ul>
<h3>
SEDS</h3>
Till today 20 SEDS are recorded in the SC4 database:
<br>
<table BORDER WIDTH="100%" >
<tr>
<td>SEDS #</td>
<td>Clause</td>
<td>Summary</td>
<td>Status</td>
</tr>
<tr>
<td>178</td>
<td></td>
<td>Global Unique Identifier (GUID) is a STEP. Sanford, Dave</td>
<td>C</td>
</tr>
<tr>
<td>269</td>
<td></td>
<td>multi_language_string for descrition attributes, Huau, Pascal, C</td>
<td>C</td>
</tr>
<tr>
<td>311</td>
<td>A.2.2</td>
<td>Example not given in valid part21 format</td>
<td>O</td>
</tr>
<tr>
<td>340</td>
<td>A.2.2</td>
<td>Example not given in valid part21 format</td>
<td>O</td>
</tr>
<tr>
<td>393</td>
<td>6.4.15</td>
<td>Order of entity attributes</td>
<td>O</td>
</tr>
<tr>
<td>394</td>
<td>6.4.12</td>
<td>Keep order in SUBTYPE statement</td>
<td>O</td>
</tr>
<tr>
<td>395</td>
<td>6, 10.9.1</td>
<td>Missing sub-supertype expressions</td>
<td>O</td>
</tr>
<tr>
<td>396</td>
<td>10.15.1</td>
<td>Allow Get By Index also for SET and BAG</td>
<td>O</td>
</tr>
<tr>
<td>397</td>
<td>10.10.1</td>
<td>domain for get inverse attributes</td>
<td>O</td>
</tr>
<tr>
<td>398</td>
<td>A.1</td>
<td>Clarification on schema_instance</td>
<td>O</td>
</tr>
<tr>
<td>399</td>
<td>6.4.2</td>
<td>interface_specification</td>
<td>O</td>
</tr>
<tr>
<td>400</td>
<td>6.4.3</td>
<td>Referencing a foreign schema</td>
<td>O</td>
</tr>
<tr>
<td>401</td>
<td>6.4.4</td>
<td>Reference named_type with EXPRESS short forms</td>
<td>O</td>
</tr>
<tr>
<td>402</td>
<td>6.4.8</td>
<td>Referencing an external schema</td>
<td>O</td>
</tr>
<tr>
<td>403</td>
<td>6.4.9</td>
<td>Referencing a named_type through an express_id</td>
<td>O</td>
</tr>
<tr>
<td>404</td>
<td>6</td>
<td>SDAI_dictionary_schema is on a meta level</td>
<td>O</td>
</tr>
<tr>
<td>405</td>
<td>9</td>
<td>Rename xxx_instance to xxx_entity, xxx_aggregate ...</td>
<td>O</td>
</tr>
<tr>
<td>406</td>
<td>D.9</td>
<td>Incorrect diagram 2 (in FDIS, corrected for IS)</td>
<td>O</td>
</tr>
<tr>
<td>409</td>
<td>D.4</td>
<td>Spelling error in diagram 4</td>
<td>O</td>
</tr>
<tr>
<td>497</td>
<td>9.3.1</td>
<td>"primitive" does not contain "select_aggregate_instance"</td>
<td>O</td>
</tr>
</table>
<h3>
Concurrent SDAI access and dynamic repositories</h3>
For SDAI-1 the following is out of scope:
<ul>
<li>
the complete specification of the behaviour of an SDAI implementations
in a multi-user environment;<br>
NOTE 1 - An SDAI implementation is not precluded from providing multi-user
data sharing access where the behaviour of the implementation depends on
the underlying data storage technology.</li>
<li>
specific support for establishing a connection to a remote data repository;<br>
NOTE 2 - An SDAI implementation is not precluded from providing access
to a remote data repository via some other mechanism.</li>
<li>
creation, deletion, and naming of the data repositories available via the
SDAI.</li>
</ul>
The requirement for SDAI-2 is to bring these topics into scope!
<br>In detail it is required to have:
<ul>
<li>
Extend for multiple SDAI-Sessions running in parallel, with every SDAI-Session
having it's own set of application data and transaction.</li>
<li>
Provide a default SDAI operation for login and logout to an SDAI-Session,
but keep details of possible access right structure to the implementation.</li>
<li>
Support for SDAI repositories shared concurently between several SDAI-Seesions,
e.g. remote SDAI repositories.</li>
<li>
Add a locking mechanism for SDAI-Repository, SDAI-Model, and Schema-Instance.</li>
<li>
Extend the functionality of SDAI-Transactions to allow an application to
update the (remote) data for any possible changes without terminating the
transaction.</li>
<li>
Provide a notification mechanism of changes on SDAI-Repository, SDAI-Model,
Schema-Instance and single entity instances</li>
<li>
Allow to dynamically create, delete and rename SDAI-Repositories within
an SDAI-Session, but outside of an SDAI-transaction.</li>
<li>
Allow to dynamically link to remote SDAI-Repositories and to un-link as
needed.</li>
<li>
Being able to specifiy the physical location of an SDAI repository, e.g.
on some remote location.</li>
</ul>
<h3>
Implementation request</h3>
Further requirements from implementors:
<ul>
<li>
Explicit EXPRESS short form support,</li>
<li>
Simplification in the handling of entity instance attributes and aggregate
members</li>
<li>
Introduction of a general purpose "EXPRESS datatype instance" concept,
covering the <b>primitve</b> entity in the SDAI_parameter_data_schema on
an object basis and not via a select type.</li>
<li>
SDAI operations to import part-21 files into SDAI and to export such files.
This requires a standard mapping between SDAI and part21.</li>
<li>
Harmonize the Schema-Instance construct with the part21.2 POPULATION feature</li>
<li>
Explicit support of part 28</li>
</ul>
<h2>
Further details</h2>
<h3>
<a NAME="sdai_repository"></a>SDAI Repository</h3>
SDAI defines that all SDAI repositories are static while an SDAI session
is open. The repositories are available by the attribute known_servers
of Sdai-session. This concept is too restrictive. An SDAI implementation
needs dynamic handling of repositories while an SDAI session is open.
<h4>
<a NAME="import_export"></a>Import and export of exchange files</h4>
One of the big lacks of SDAI is that there is no relation to physical files
as defined in part21 (clear text encoding of the exchange structure). But
this is a very basic feature of EVERY SDAI implementation. Part 27 already
defines a mapping between part21 and SDAI and associated import and export
operations.
<h4>
<a NAME="repository_attributes"></a>Additional attributes</h4>
Part 21 (and also part 28) defines several information in the header section
which do not have a counterparts in SDAI. Because a part21 file can be
mapped to either an SDAI-Repository or a Schema-Instance it makes sense
to add these attributes to both of them. The missing string- attributes
are:
<ul>
<li>
time-stamp</li>
<li>
author</li>
<li>
organization</li>
<li>
preprocessor-version</li>
<li>
originating-system</li>
<li>
authorization</li>
</ul>
<h4>
<a NAME="create_delete"></a>Creating, deletion, temporarily repositories</h4>
Applications needs to create new repositories, delete repositories which
are no longer needed and to create temporarily repositories which exist
only as long as an SDAI-session is running.
<h4>
<a NAME="remote_repository"></a>Remote repositories</h4>
Explicit network support is required to access remote repositories. While
an SDAI session is (still) defined in single user mode, a remote repository
may run in a client - server mode for several clients simultaneously. The
usage of a URL as a repository name is recommended; e.g. "repo1.lksoft.de".
<h3>
SDAI model</h3>
<h4>
<a NAME="copy_sdai_model"></a>Copying and moving of SDAI models</h4>
SDAI defines the operation Copy Application Instance (ISO 10303:10.11.1)
to copy a single instance. We find it useful to have an operation to copy
and move a complete SDAI-model with it's contents from one repository to
another.
<h4>
Moving entity instances and changing their type</h4>
Operations are needed to change the type of an instance and to move the
instance into another model/repository while maintaining all relations
from other entity instances.
<h3>
SDAI_dictionary_schema</h3>
<h4>
<a NAME="Data_types"></a>Data-types</h4>
WG3N105 defines an early draft of a Semantic Meta Model of EXPRESS. Is
is given in graphically form only. Bigger parts of this model are based
on discussions at an EXPRESS workshop at NIST in 1999. This model has a
bigger overlap with the SDAI_dictionary_schema, however it is quite different.
The concepts of generic datatypes are used in this proposal.
<h4>
<a NAME="sub_super"></a>Sub-supertype restrictions: ONEOF, AND, ANDOR</h4>
The SDAI_dictionary_schema does only cover the sub-supertype relation between
entity_definions, but not it's restrictions given by the <b>ONEOF</b>,
<b>AND</b>
and <b>ANDOR</b> keywords. This was felt to be unnecessary because instances
of entity_definiton are also used for complex types definitions on which
complex instances are based on. Annex A.1.3 defines two possibilities of
how to create complex entity types, one is that all possible complex types
exist from the beginning, the other is that complex types are generated
during runtime by the <i>get complex entity definition</i> (ISO 10303-22:10.9.1).
For the later case an explicit modeling of the ONEOF, AND and ANDOR keywords
and also the extended features of EXPRESS version 2 are needed.
<h4>
<a NAME="short_form"></a>EXPRESS short forms</h4>
The SDAI dictionary schema works on a long-form basis only. All USE and
REFERENCE FROM directives are resolved (see ISO 10303:A.1.1) into a local
population of the SDAI_dictionary_schema. The <i>domain equivalence information</i>
(ISO 10303-22:A.2) can be used to re-engineer the original short-form information.
<p>Practical usage of the SDAI_dictionary_schema has shown that the <i>domain
equivalence information</i> is a possible solution to allow APs interoperability.
But having the explicit short-form information would be much better. Especially
when going to the new Modularization Approach (WG10) direct availability
of the short form has many benefits.
<h4>
<a NAME="functions_expressions"></a>Functions & Expressions</h4>
The SDAI_dictionary_schema supports global and where rules and there are
also operators to verify such rules. But functions, expression, statements,
variables and constants are not included. Because SDAI itself can be used
to emulate expressions and functions this stuff shall also be included
in the SDAI dictionary schema.
<h2>
Proposed changes and extensions</h2>
We assume, that the principle structure and functionality of SDAI remains
unchanged. The idea is to be upward compatible as much as possible, but
to change and extend things as needed. The proposed changes do not fullfil
all requirements so far.
<h3>
Clause 1: Scope</h3>
- Explicit support of multiple users in such a way, that each user has
its own SDAI-Session, SDAI-Repositories and all other SDAI objects
<br>- locking and unlocking of SDAI-Repository, SDAI-Model, and Schema-Instance
<br>- Event mechanism
<br>- Specific support for establishing a connection to a remote data repository
<br>- Creation, deletetion and naming of the data repositories available
via the SDAI
<h3>
Clause 4: SDAI overview</h3>
<h3>
Clause 5: Fundamental principles</h3>
<h3>
<a NAME="SDAI_dictionary_schema"></a>Clause 6: SDAI_dictionary_schema</h3>
The SDAI_dictionary_schema is defined in clause 6 of SDAI. It uses EXPRESS
on a meta level to describe the structure of EXPRESS itself. It proofs
that this concept is very powerful, however there are several limitations.
These limitations are mainly caused in the fact that the SDAI_dictionary_schema
describes EXPRESS not at 100%. See attached the proposal for an extended
dictionary schema.
<h3>
Clause 7: SDAI session schema</h3>
<h3>
Clause 8: SDAI population schema</h3>
<h3>
Clause 9: SDAI parameter data schema</h3>
<h4>
<a NAME="dictionary_as_application"></a>Use Dictionary Entites like Application
Entities</h4>
There is no principle reason why instances of the dictionary entities shall
not be dynamic similar to the Application entities. An application may
e.g. wish to create new entity-types. It is planned to extend the clear
text encoding of the exchange structure (ISO 10303-21) so that it contains
multiple data sections. One data-section may then contain an EXPRESS schema,
while another data section may contains a population of this express_schema.
SDAI shall support this. E.g.:
<p>Instead of 2 files with
<blockquote>ENTITY static
<br> name:STRING;
<br>END_ENTITY</blockquote>
and
<blockquote>#10=STATIC('no chance to change me')</blockquote>
There may be one file with
<blockquote>-- data section A, based on the SDAI_dictionary_schema
<br>#10=schema_definition('new_schema', $)
<br>#20=entity_definition('dynamic', #10, ...)
<br>#30=explicit_attribute('name', #20, ...)
<br>-- data section B, based on #10
<br>#40=#20('I m dynamic')</blockquote>
<h2>
<a NAME="diverse"></a>Diverse</h2>
<h3>
<a NAME="exception"></a>Exception mechanisms</h3>
At the time when the SDAI was developed C++ did not have Exception and
Java did not exist. Because of this exceptions where not taken into account
when specifying the error and event handling mechanism of SDAI. Because
of the late introduction of Exceptions in C++ it is still not widely used
there, but Java is fully based of this mechanism. Also the SDAI mapping
to Java are all based on exception for any kind of error condition. SDAI
should be updated to reflect this.
<h3>
<a NAME="entity_extent"></a>Improving the organization of entity instances</h3>
SDAI groups all entity instances of one model into Entity Extents. An entity
extent contains all instances of a given entity type or subtypes of it.
Because of this an implementation cannot use the entity extents as the
internal data structure. For efficiency reasons an application will group
all instances of exactly one entity type without it's subtype. Based on
such a structure the behaviour of entity-extends can be easily emulated,
similar to the aggregate sdai_model_contents.instances. SDAI should be
updated to reflect this.
<h3>
<a NAME="base_entity"></a>Application Entity instead of Application Instance</h3>
The wording in the SDAI_parameter_data_schema is missleading. It contains
definitions of the entities entity_instance, application_instance, sdai_instance,
session_instance and dictionary_instance but these are all entity type
definitions. Because of this they should be renamed to base_entity, application_entity,
sdai_entity, session_entity, dictionary_entity.
<p>All entities in the dictionary_schema should be implicit subtypes of
the dictionary_entity.
<br>All entities from application schemas should be implicit subtypes of
application_entity.
<br>All entities from the session and population schema shall be explicit
subtypes of the session_entity.
<h3>
<a NAME="scope"></a>No Scope</h3>
Scope is a feature which is going to be removed from the physical file
(part 21). It is also not used in several language bindings and not used
by any known implementation of SDAI. Because it's usage is unclear people
agreed to not use it. As a consequence it should be removed also from SDAI.
<br>
<hr WIDTH="100%">
<dl>(** version 3.1 2002-02-18 *)
<br>SCHEMA SDAI_dictionary_schema;
<p>TYPE base_type = SELECT
<br> (simple_type,
<br> aggregation_type,
<br> named_type);
<br>END_TYPE;
<p>TYPE constructed_type = SELECT
<br> (enumeration_type,
<br> select_type);
<br>END_TYPE;
<p>TYPE declaration_type = SELECT
<br> (named_type,
<br> global_rule,
<br> algorithm_definition,
<br> constant_definition,
<br> map_definition);
<br>END_TYPE;
<p>TYPE documentation_object = SELECT
<br> (schema_definition,
<br> constant_definition,
<br> named_type,
<br> attribute,
<br> algorithm_definition,
<br> global_rule,
<br> where_rule
<br> );
<br>END_TYPE;
<p>TYPE entity_or_view_or_subtype_expression = SELECT (
<br> entity_or_view_definition,
<br> subtype_expression);
<br>END_TYPE;
<p>TYPE explicit_or_derived = SELECT
<br> (explicit_attribute,
<br> derived_attribute);
<br>END_TYPE;
<p>TYPE express_id = STRING;
<br>END_TYPE;
<p>TYPE info_object_id = STRING;
<br>END_TYPE;
<p>TYPE map_or_view_select = SELECT
<br> (map_definition,
<br> view_definition,
<br> map_partition,
<br> view_partition);
<br>END_TYPE;
<p>TYPE schema_map_or_view_definition = SELECT
<br> (schema_view_definition,
<br> schema_map_definition);
<br>END_TYPE;
<p>TYPE type_or_rule = SELECT
<br> (named_type,
<br> global_rule);
<br>END_TYPE;
<p>TYPE underlying_type = SELECT
<br> (simple_type,
<br> aggregation_type,
<br> defined_type,
<br> constructed_type);
<br>END_TYPE;
<p>(* not abstract because of generic aggregates *)
<br>ENTITY aggregation_type
<br> SUPERTYPE OF (ONEOF(variable_size_aggregation_type, array_type))
<br> SUBTYPE OF (data_type);
<br> element_type : data_type;
<br>END_ENTITY;
<p>ENTITY algorithm_declaration
<br> ABSTRACT SUPERTYPE OF (ONEOF (function_declaration, procedure_declaration))
<br> SUBTYPE OF (declaration);
<br>END_ENTITY;
<p>ENTITY algorithm_definition
<br> ABSTRACT SUPERTYPE OF (ONEOF (function_definition, procedure_definition));
<br> name : express_id;
<br> parameters : LIST[0:?] OF parameter;
<br>END_ENTITY; -- algorithm_definition
<p>ENTITY andor_subtype_expression
<br> SUBTYPE OF (subtype_expression);
<br>END_ENTITY;
<p>ENTITY and_subtype_expression
<br> SUBTYPE OF (subtype_expression);
<br>END_ENTITY;
<p>ENTITY annotation
<br> ABSTRACT SUPERTYPE OF (ONEOF (documentation, express_code));
<br> target : documentation_object;
<br> values : LIST [1:?] OF STRING;
<br>END_ENTITY; -- annotation
<p>(* OPTIONAL bounds only in the case of generic array *)
<br>ENTITY array_type
<br> SUBTYPE OF (aggregation_type);
<br> lower_index : OPTIONAL bound;
<br> upper_index : OPTIONAL bound;
<br> unique_flag : BOOLEAN;
<br> optional_flag : BOOLEAN;
<br>END_ENTITY;
<p>(* maybe also to introduce alias_attribute for EXPRESS_2 ?*)
<br>ENTITY attribute
<br> ABSTRACT SUPERTYPE OF (ONEOF(derived_attribute,explicit_attribute,inverse_attribute,view_attribute));
<br> name : express_id;
<br> parent_entity : entity_or_view_definition;
<br> order : OPTIONAL INTEGER;
<br>END_ENTITY;
<p>ENTITY bag_type
<br> SUBTYPE OF (variable_size_aggregation_type);
<br>END_ENTITY;
<p>ENTITY binary_type
<br> SUBTYPE OF (simple_type);
<br> width : OPTIONAL bound;
<br> fixed_width : BOOLEAN;
<br>END_ENTITY;
<p>ENTITY boolean_type
<br> SUBTYPE OF (simple_type);
<br>END_ENTITY;
<p>ENTITY bound
<br> ABSTRACT SUPERTYPE OF (ONEOF(integer_bound,population_dependent_bound));
<br>END_ENTITY;
<p>ENTITY constant_declaration
<br> SUBTYPE OF (declaration);
<br>END_ENTITY;
<p>ENTITY constant_definition;
<br> name : express_id;
<br> domain : base_type;
<br> constant_value : base_type; -- should be ENTITY here
<br>END_ENTITY;
<p>(* not abstract since it can be used for GENERIC *)
<br>ENTITY data_type
<br> SUPERTYPE OF
<br> (ONEOF(named_type, enumeration_type, select_type, simple_type,
aggregation_type));
<br> name : express_id;
<br>END_ENTITY;
<p>ENTITY data_type_declaration
<br> SUPERTYPE OF
<br> (ONEOF(entity_declaration, type_declaration))
<br> SUBTYPE OF (declaration);
<br>END_ENTITY;
<p>ENTITY declaration
<br> ABSTRACT SUPERTYPE OF (ONEOF(interfaced_declaration, local_declaration)
<br> AND ONEOF(data_type_declaration, rule_declaration,
<br> algorithm_declaration, constant_declaration));
<br> parent_schema : generic_schema_definition;
<br> definition : declaration_type;
<br>END_ENTITY;
<p>ENTITY defined_type
<br> SUBTYPE OF (named_type);
<br> domain : underlying_type;
<br>END_ENTITY;
<p>ENTITY dependent_map_definition
<br> SUBTYPE OF (map_definition);
<br>END_ENTITY;
<p>ENTITY dependent_view_definition
<br> SUBTYPE OF (view_definition);
<br> domain : OPTIONAL base_type;
<br>END_ENTITY;
<p>ENTITY derived_attribute
<br> SUBTYPE OF (attribute);
<br> domain : base_type;
<br> redeclaring : OPTIONAL explicit_or_derived;
<br> SELF\attribute.parent_entity : entity_definition;
<br>END_ENTITY;
<p>ENTITY documentation
<br> SUBTYPE OF (annotation);
<br>END_ENTITY; -- documentation
<p>ENTITY domain_equivalent_type;
<br> external_type : named_type;
<br> native_type : named_type;
<br> owner : external_schema;
<br>END_ENTITY;
<p>ENTITY entity_declaration
<br> SUBTYPE OF (data_type_declaration);
<br> SELF\declaration.parent_schema : schema_definition;
<br> SELF\declaration.definition : entity_definition;
<br>END_ENTITY;
<p>ENTITY entity_definition
<br> SUBTYPE OF (entity_or_view_definition);
<br> complex : BOOLEAN;
<br> instantiable : BOOLEAN;
<br> independent : BOOLEAN;
<br> SELF\entity_or_view_definition.supertypes : LIST [0:?] OF UNIQUE
entity_definition;
<br> INVERSE
<br> attributes : SET[0:?] OF attribute FOR parent_entity;
<br> uniqueness_rules : SET[0:?] OF uniqueness_rule FOR parent_entity;
<br> global_rules : SET[0:?] OF global_rule FOR entities;
<br>END_ENTITY;
<p>ENTITY entity_or_view_definition
<br> ABSTRACT SUPERTYPE OF (ONEOF (entity_definition, view_definition))
<br> SUBTYPE OF (named_type);
<br> supertypes : LIST [0:?] OF UNIQUE entity_or_view_definition;
<br>END_ENTITY;
<p>ENTITY enumeration_type
<br> SUBTYPE OF (data_type);
<br> elements : LIST [1:?] OF UNIQUE express_id;
<br>END_ENTITY;
<p>ENTITY explicit_attribute
<br> SUBTYPE OF (attribute);
<br> domain : base_type;
<br> redeclaring : OPTIONAL explicit_attribute;
<br> optional_flag : BOOLEAN;
<br> SELF\attribute.parent_entity : entity_definition;
<br>END_ENTITY;
<p>ENTITY express_code
<br> SUBTYPE OF (annotation);
<br>END_ENTITY;
<p>ENTITY external_schema;
<br> definition : schema_definition;
<br> native_schema : schema_definition;
<br> INVERSE
<br> for_types : SET[1:?] OF domain_equivalent_type FOR owner;
<br>END_ENTITY;
<p>ENTITY function_declaration
<br> SUBTYPE OF (algorithm_declaration);
<br>END_ENTITY;
<p>ENTITY function_definition
<br> SUBTYPE OF (algorithm_definition);
<br> return_type : data_type;
<br> return_type_label : OPTIONAL express_id;
<br>END_ENTITY; -- function_definition
<p>ENTITY generic_schema_definition
<br> ABSTRACT SUPERTYPE OF (ONEOF(schema_definition, schema_view_definition,
schema_map_definition));
<br> name : express_id;
<br> identification : OPTIONAL info_object_id;
<br> UNIQUE
<br> UR1: identification;
<br>END_ENTITY;
<p>ENTITY global_rule;
<br> name : express_id;
<br> entities : LIST [1:?] OF entity_definition;
<br> INVERSE
<br> where_rules : SET [1:?] OF where_rule FOR parent_item;
<br>END_ENTITY;
<p>ENTITY implicit_declaration
<br> SUBTYPE OF (interfaced_declaration);
<br>END_ENTITY;
<p>ENTITY independent_view_definition
<br> SUBTYPE OF (view_definition);
<br>END_ENTITY;
<p>ENTITY integer_bound
<br> SUBTYPE OF (bound);
<br> bound_value : INTEGER;
<br>END_ENTITY;
<p>ENTITY integer_type
<br> SUBTYPE OF (simple_type);
<br>END_ENTITY;
<p>ENTITY interfaced_declaration
<br> ABSTRACT SUPERTYPE OF
<br> (ONEOF(implicit_declaration, used_declaration, referenced_declaration))
<br> SUBTYPE OF (declaration);
<br> alias_name : OPTIONAL express_id;
<br>END_ENTITY;
<p>ENTITY inverse_attribute
<br> SUBTYPE OF (attribute);
<br> domain : entity_definition;
<br> redeclaring : OPTIONAL inverse_attribute;
<br> inverted_attr : explicit_attribute;
<br> min_cardinality : OPTIONAL bound;
<br> max_cardinality : OPTIONAL bound;
<br> duplicates : BOOLEAN;
<br> SELF\attribute.parent_entity : entity_definition;
<br>END_ENTITY;
<p>ENTITY list_type
<br> SUBTYPE OF (variable_size_aggregation_type);
<br> unique_flag : BOOLEAN;
<br>END_ENTITY;
<p>ENTITY local_declaration
<br> SUBTYPE OF (declaration);
<br>END_ENTITY;
<p>ENTITY logical_type
<br> SUBTYPE OF (simple_type);
<br>END_ENTITY;
<p>ENTITY map_declaration
<br> SUBTYPE OF (data_type_declaration);
<br> SELF\declaration.parent_schema : schema_map_definition;
<br> SELF\declaration.definition : map_definition;
<br>END_ENTITY;
<p>ENTITY map_definition;
<br> name : express_id;
<br>END_ENTITY;
<p>ENTITY map_partition;
<br> parent : map_definition;
<br> name : express_id;
<br>END_ENTITY;
<p>ENTITY named_type
<br> ABSTRACT SUPERTYPE OF (ONEOF(defined_type, entity_definition))
<br> SUBTYPE OF (data_type);
<br> short_name : OPTIONAL STRING;
<br> INVERSE
<br> where_rules : SET [0:?] OF where_rule FOR parent_item;
<br>END_ENTITY;
<p>ENTITY number_type
<br> SUBTYPE OF (simple_type);
<br>END_ENTITY;
<p>ENTITY oneof_subtype_expression
<br> SUBTYPE OF (subtype_expression);
<br>END_ENTITY;
<p>ENTITY parameter;
<br> name : express_id;
<br> parameter_type : data_type;
<br> var_type : BOOLEAN;
<br> (* type labels may occur nested, e.g. X and Y in 'AGGREGATE:X
OF GENERIC:Y' *)
<br> type_labels: OPTIONAL LIST [1:?] OF express_id;
<br>END_ENTITY;
<p>ENTITY population_dependent_bound
<br> SUBTYPE OF (bound);
<br>END_ENTITY;
<p>ENTITY procedure_declaration
<br> SUBTYPE OF (algorithm_declaration);
<br>END_ENTITY;
<p>ENTITY procedure_definition
<br> SUBTYPE OF (algorithm_definition);
<br>END_ENTITY; -- procedure_definition
<p>ENTITY real_type
<br> SUBTYPE OF (simple_type);
<br> precision : OPTIONAL bound;
<br>END_ENTITY;
<p>ENTITY referenced_declaration
<br> SUBTYPE OF (interfaced_declaration);
<br>END_ENTITY;
<p>ENTITY rule_declaration
<br> SUBTYPE OF (declaration);
<br>END_ENTITY;
<p>ENTITY schema_definition
<br> SUBTYPE OF (generic_schema_definition);
<br> INVERSE
<br> entity_declarations : SET[0:?] OF entity_declaration FOR parent_schema;
<br> type_declarations : SET[0:?] OF type_declaration FOR parent_schema;
<br> rule_declarations : SET[0:?] OF rule_declaration FOR parent_schema;
<br> algorithm_declarations : SET[0:?] OF algorithm_declaration FOR
parent_schema;
<br> external_schemas : SET[1:?] OF external_schema FOR native_schema;
<br>END_ENTITY;
<p>ENTITY schema_map_definition
<br> SUBTYPE OF (generic_schema_definition);
<br> INVERSE
<br> view_declarations : SET[0:?] OF view_declaration FOR parent_schema;
<br> map_declarations : SET[0:?] OF map_declaration FOR parent_schema;
<br>END_ENTITY;
<p>ENTITY schema_view_definition
<br> SUBTYPE OF (generic_schema_definition);
<br> INVERSE
<br> view_declarations : SET[0:?] OF view_declaration FOR parent_schema;
<br>END_ENTITY;
<p>ENTITY select_type
<br> SUBTYPE OF (data_type);
<br> selections : SET [1:?] OF named_type;
<br>END_ENTITY;
<p>ENTITY set_type
<br> SUBTYPE OF (variable_size_aggregation_type);
<br>END_ENTITY;
<p>ENTITY simple_type
<br> ABSTRACT SUPERTYPE OF (ONEOF(integer_type,number_type,real_type,boolean_type,logical_type,binary_type,string_type))
<br> SUBTYPE OF (data_type);
<br>END_ENTITY;
<p>ENTITY source_parameter;
<br> name : express_id;
<br> parent : map_or_view_select;
<br> extent : entity_or_view_definition;
<br> order : INTEGER;
<br>END_ENTITY;
<p>ENTITY string_type
<br> SUBTYPE OF (simple_type);
<br> width : OPTIONAL bound;
<br> fixed_width : BOOLEAN;
<br>END_ENTITY;
<p>ENTITY subtype_constraint;
<br> name : OPTIONAL express_id;
<br> super_type : entity_or_view_definition;
<br> constraint : subtype_expression;
<br>END_ENTITY;
<p>ENTITY subtype_expression ABSTRACT SUPERTYPE OF
<br>(ONEOF (andor_subtype_expression, and_subtype_expression, oneof_subtype_expression));
<br> operands : SET [1:?] OF entity_or_view_or_subtype_expression;
<br>END_ENTITY;
<p>ENTITY target_parameter;
<br> name : express_id;
<br> parent : map_definition;
<br> extent : entity_definition;
<br> lower_bound : INTEGER;
<br> upper_bound : OPTIONAL INTEGER;
<br> order : INTEGER;
<br>END_ENTITY;
<p>ENTITY type_declaration
<br> SUBTYPE OF (data_type_declaration);
<br> SELF\declaration.parent_schema : schema_definition;
<br> SELF\declaration.definition : defined_type;
<br>END_ENTITY;
<p>ENTITY uniqueness_rule;
<br> label : OPTIONAL express_id;
<br> attributes : LIST [1:?] OF attribute;
<br> parent_entity : entity_definition;
<br>END_ENTITY;
<p>ENTITY used_declaration
<br> SUBTYPE OF (interfaced_declaration);
<br>END_ENTITY;
<p>ENTITY variable_size_aggregation_type
<br> ABSTRACT SUPERTYPE OF (ONEOF(bag_type,set_type,list_type))
<br> SUBTYPE OF (aggregation_type);
<br> lower_bound : OPTIONAL bound;
<br> upper_bound : OPTIONAL bound;
<br>END_ENTITY;
<p>ENTITY view_attribute
<br> SUBTYPE OF (attribute);
<br> SELF\attribute.parent_entity : independent_view_definition;
<br>END_ENTITY;
<p>ENTITY view_declaration
<br> SUBTYPE OF (data_type_declaration);
<br> SELF\declaration.parent_schema : schema_map_or_view_definition;
<br> SELF\declaration.definition : view_definition;
<br>END_ENTITY;
<p>ENTITY view_definition
<br> ABSTRACT SUPERTYPE OF (ONEOF(independent_view_definition, dependent_view_definition))
<br> SUBTYPE OF (entity_or_view_definition);
<br> SELF\entity_or_view_definition.supertypes : LIST [0:?] OF UNIQUE
entity_definition;
<br>(*DERIVED
<br> binding_extent : LIST [1:?] OF source_parameter;
<br>*)
<br>END_ENTITY;
<p>(** If no partitions are explicitly defined we may assume an implicit
one *)
<br>ENTITY view_partition;
<br> parent : view_definition;
<br> name : express_id;
<br>END_ENTITY;
<p>ENTITY view_partition_attribute;
<br> parent_view_attribute : view_attribute;
<br> related_partition : view_partition;
<br>END_ENTITY;
<p>ENTITY where_rule;
<br> label : OPTIONAL express_id;
<br> parent_item : type_or_rule;
<br> order : INTEGER;
<br>END_ENTITY;
<p>END_SCHEMA;
<br> </dl>
</body>
</html>