<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Mapping Table Schema</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="Lothar Klein" name=Author>
<META content="MSHTML 6.00.2713.1100" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=150570109-20022002>Lothar,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=150570109-20022002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=150570109-20022002>Can
this me amended so it says who's requirements these are? I can't tell if
the source is LKSoft, a workshop or WG11 as a whole.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=150570109-20022002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=150570109-20022002>Cheers,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=150570109-20022002>David</SPAN></FONT></DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> owner-wg11@steptools.com
[mailto:owner-wg11@steptools.com]<B>On Behalf Of </B>Lothar
Klein<BR><B>Sent:</B> 2002 February 19 11:51<BR><B>To:</B> Teresa Brittingham;
wg11@steptools.com<BR><B>Subject:</B> WG11N191: Requirements for the second
edition of SDAI<BR><BR></FONT></DIV>
<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>ISO 10303-24:2001 for the C binding
<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>The IDL/Corba binding which sucessfully passes the CD ballot has been
canceled due to lack of activities.
<LI>The lightweight Java binding (ISO/CD 10303-29) did not progress for the
last 2 years.
<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>EPM Technologies (ST-Developer)
<LI>LKSoft (JSDAI)
<LI>ProSTEP (IDA CaseLib)
<LI>Softlab (GEP)
<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>extensible enumerations
<LI>total-over
<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>Specifying a domain (SdaiModel) in which new entity instances are
created during executing of derived attributes.
<LI>extending the SDAI_dictionary_schema for generic data types, used in
procedure and functions
<LI>Adding new operations to execute E-X <B>schema-map</B> and <B>map</B>
<LI>Extend the SDAI_parameter_data_schema for instances of E-X views
<LI>Add operations to create view instance </LI></UL>
<H3>SEDS</H3>Till today 20 SEDS are recorded in the SC4 database: <BR>
<TABLE width="100%" border=1>
<TBODY>
<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></TBODY></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>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>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>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>Support for SDAI repositories shared concurently between several
SDAI-Seesions, e.g. remote SDAI repositories.
<LI>Add a locking mechanism for SDAI-Repository, SDAI-Model, and
Schema-Instance.
<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>Provide a notification mechanism of changes on SDAI-Repository,
SDAI-Model, Schema-Instance and single entity instances
<LI>Allow to dynamically create, delete and rename SDAI-Repositories within
an SDAI-Session, but outside of an SDAI-transaction.
<LI>Allow to dynamically link to remote SDAI-Repositories and to un-link as
needed.
<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>Simplification in the handling of entity instance attributes and
aggregate members
<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>SDAI operations to import part-21 files into SDAI and to export such
files. This requires a standard mapping between SDAI and part21.
<LI>Harmonize the Schema-Instance construct with the part21.2 POPULATION
feature
<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>author
<LI>organization
<LI>preprocessor-version
<LI>originating-system
<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> </P></DL></BLOCKQUOTE></BODY></HTML>