WG11N191: Requirements for the second edition of SDAI
David Price
david.price at eurostep.com
Wed Feb 20 04:09:35 EST 2002
Mapping Table SchemaLothar,
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.
Cheers,
David
-----Original Message-----
From: owner-wg11 at steptools.com [mailto:owner-wg11 at steptools.com]On Behalf
Of Lothar Klein
Sent: 2002 February 19 11:51
To: Teresa Brittingham; wg11 at steptools.com
Subject: WG11N191: Requirements for the second edition of SDAI
ISO TC184/SC4/WG11/N191
Date: 2001-01-31
supersseds ISO TC184/SC4/WG11/N068
SDAI-2
Requirements for the second edition of SDAI
Lothar Klein (lothar.klein at lksoft.com)
Vaidas Nargelas (vaidas.nargelas at lksoft.lt)
LKSoftWare GmbH (http://www.lksoft.com)
----------------------------------------------------------------------------
--
Contents
Introduction
SDAI_dictionary_schema
Data-types
Sub-supertype restrictions: ONEOF, AND, ANDOR
EXPRESS short forms
Functions & Expressions
Mapping Tables
Use Dictionary Entites like Application Entities
SDAI Repository
Import and export of exchange files
Additional attributes
Creating, deletion, temporarily repositories
Remote repositories
Copying an SDAI model
Usage of SDAI models
Diverse
Exception mechanisms
Improving the organization of entity instances
Application Entity instead of Application Instance
No Scope
Introduction
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:
a.. ISO 10303-23:2000 for the C++ binding
b.. ISO 10303-24:2001 for the C binding
c.. ISO/TS 10303-27:2000 for the (complete) Java(TM) binding
Other SDAI based standardisation activities:
a.. The planned Fortran binding has been canceled.
b.. The IDL/Corba binding which sucessfully passes the CD ballot has
been canceled due to lack of activities.
c.. The lightweight Java binding (ISO/CD 10303-29) did not progress for
the last 2 years.
d.. The "Abstract Test Methods for SDAI Implementations" is under work.
It has sucessfully passed its CD ballot in October 2001.
Commerial SDAI implementations are available from (source PDES.Inc
website)
a.. Bentley (Microstation)
b.. EPM Technologies (ST-Developer)
c.. LKSoft (JSDAI)
d.. ProSTEP (IDA CaseLib)
e.. Softlab (GEP)
f.. StepTools (ST-Developer)
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.
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".
Requirements
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.
EXPRESS Edition 2 (Amenmend) support
The actual document for the 2nd version of EXPRESS (called the EXPRESS
Amenment) has several new features to be supported by SDAI:
a.. extensible selects
b.. extensible enumerations
c.. total-over
d.. separte subtype constraints
EXPRESS-X and expression support
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.
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.
The requirements is to extend SDAI for
a.. Operations to execute EXPRESS functions and procedures
b.. Specifying a domain (SdaiModel) in which new entity instances are
created during executing of derived attributes.
c.. extending the SDAI_dictionary_schema for generic data types, used in
procedure and functions
d.. Adding new operations to execute E-X schema-map and map
e.. Extend the SDAI_parameter_data_schema for instances of E-X views
f.. Add operations to create view instance
SEDS
Till today 20 SEDS are recorded in the SC4 database:
SEDS # Clause Summary Status
178 Global Unique Identifier (GUID) is a STEP. Sanford, Dave C
269 multi_language_string for descrition attributes, Huau, Pascal,
C C
311 A.2.2 Example not given in valid part21 format O
340 A.2.2 Example not given in valid part21 format O
393 6.4.15 Order of entity attributes O
394 6.4.12 Keep order in SUBTYPE statement O
395 6, 10.9.1 Missing sub-supertype expressions O
396 10.15.1 Allow Get By Index also for SET and BAG O
397 10.10.1 domain for get inverse attributes O
398 A.1 Clarification on schema_instance O
399 6.4.2 interface_specification O
400 6.4.3 Referencing a foreign schema O
401 6.4.4 Reference named_type with EXPRESS short forms O
402 6.4.8 Referencing an external schema O
403 6.4.9 Referencing a named_type through an express_id O
404 6 SDAI_dictionary_schema is on a meta level O
405 9 Rename xxx_instance to xxx_entity, xxx_aggregate ... O
406 D.9 Incorrect diagram 2 (in FDIS, corrected for IS) O
409 D.4 Spelling error in diagram 4 O
497 9.3.1 "primitive" does not contain "select_aggregate_instance" O
Concurrent SDAI access and dynamic repositories
For SDAI-1 the following is out of scope:
a.. the complete specification of the behaviour of an SDAI
implementations in a multi-user environment;
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.
b.. specific support for establishing a connection to a remote data
repository;
NOTE 2 - An SDAI implementation is not precluded from providing access
to a remote data repository via some other mechanism.
c.. creation, deletion, and naming of the data repositories available
via the SDAI.
The requirement for SDAI-2 is to bring these topics into scope!
In detail it is required to have:
a.. Extend for multiple SDAI-Sessions running in parallel, with every
SDAI-Session having it's own set of application data and transaction.
b.. Provide a default SDAI operation for login and logout to an
SDAI-Session, but keep details of possible access right structure to the
implementation.
c.. Support for SDAI repositories shared concurently between several
SDAI-Seesions, e.g. remote SDAI repositories.
d.. Add a locking mechanism for SDAI-Repository, SDAI-Model, and
Schema-Instance.
e.. Extend the functionality of SDAI-Transactions to allow an
application to update the (remote) data for any possible changes without
terminating the transaction.
f.. Provide a notification mechanism of changes on SDAI-Repository,
SDAI-Model, Schema-Instance and single entity instances
g.. Allow to dynamically create, delete and rename SDAI-Repositories
within an SDAI-Session, but outside of an SDAI-transaction.
h.. Allow to dynamically link to remote SDAI-Repositories and to un-link
as needed.
i.. Being able to specifiy the physical location of an SDAI repository,
e.g. on some remote location.
Implementation request
Further requirements from implementors:
a.. Explicit EXPRESS short form support,
b.. Simplification in the handling of entity instance attributes and
aggregate members
c.. Introduction of a general purpose "EXPRESS datatype instance"
concept, covering the primitve entity in the SDAI_parameter_data_schema on
an object basis and not via a select type.
d.. SDAI operations to import part-21 files into SDAI and to export such
files. This requires a standard mapping between SDAI and part21.
e.. Harmonize the Schema-Instance construct with the part21.2 POPULATION
feature
f.. Explicit support of part 28
Further details
SDAI Repository
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.
Import and export of exchange files
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.
Additional attributes
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:
a.. time-stamp
b.. author
c.. organization
d.. preprocessor-version
e.. originating-system
f.. authorization
Creating, deletion, temporarily repositories
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.
Remote repositories
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".
SDAI model
Copying and moving of SDAI models
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.
Moving entity instances and changing their type
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.
SDAI_dictionary_schema
Data-types
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.
Sub-supertype restrictions: ONEOF, AND, ANDOR
The SDAI_dictionary_schema does only cover the sub-supertype relation
between entity_definions, but not it's restrictions given by the ONEOF, AND
and ANDOR 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 get complex entity definition (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.
EXPRESS short forms
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 domain equivalence information
(ISO 10303-22:A.2) can be used to re-engineer the original short-form
information.
Practical usage of the SDAI_dictionary_schema has shown that the domain
equivalence information 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.
Functions & Expressions
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.
Proposed changes and extensions
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.
Clause 1: Scope
- Explicit support of multiple users in such a way, that each user has its
own SDAI-Session, SDAI-Repositories and all other SDAI objects
- locking and unlocking of SDAI-Repository, SDAI-Model, and
Schema-Instance
- Event mechanism
- Specific support for establishing a connection to a remote data
repository
- Creation, deletetion and naming of the data repositories available via
the SDAI
Clause 4: SDAI overview
Clause 5: Fundamental principles
Clause 6: SDAI_dictionary_schema
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.
Clause 7: SDAI session schema
Clause 8: SDAI population schema
Clause 9: SDAI parameter data schema
Use Dictionary Entites like Application Entities
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.:
Instead of 2 files with
ENTITY static
name:STRING;
END_ENTITY
and
#10=STATIC('no chance to change me')
There may be one file with
-- data section A, based on the SDAI_dictionary_schema
#10=schema_definition('new_schema', $)
#20=entity_definition('dynamic', #10, ...)
#30=explicit_attribute('name', #20, ...)
-- data section B, based on #10
#40=#20('I m dynamic')
Diverse
Exception mechanisms
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.
Improving the organization of entity instances
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.
Application Entity instead of Application Instance
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.
All entities in the dictionary_schema should be implicit subtypes of the
dictionary_entity.
All entities from application schemas should be implicit subtypes of
application_entity.
All entities from the session and population schema shall be explicit
subtypes of the session_entity.
No Scope
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.
----------------------------------------------------------------------------
--
(** version 3.1 2002-02-18 *)
SCHEMA SDAI_dictionary_schema;
TYPE base_type = SELECT
(simple_type,
aggregation_type,
named_type);
END_TYPE;
TYPE constructed_type = SELECT
(enumeration_type,
select_type);
END_TYPE;
TYPE declaration_type = SELECT
(named_type,
global_rule,
algorithm_definition,
constant_definition,
map_definition);
END_TYPE;
TYPE documentation_object = SELECT
(schema_definition,
constant_definition,
named_type,
attribute,
algorithm_definition,
global_rule,
where_rule
);
END_TYPE;
TYPE entity_or_view_or_subtype_expression = SELECT (
entity_or_view_definition,
subtype_expression);
END_TYPE;
TYPE explicit_or_derived = SELECT
(explicit_attribute,
derived_attribute);
END_TYPE;
TYPE express_id = STRING;
END_TYPE;
TYPE info_object_id = STRING;
END_TYPE;
TYPE map_or_view_select = SELECT
(map_definition,
view_definition,
map_partition,
view_partition);
END_TYPE;
TYPE schema_map_or_view_definition = SELECT
(schema_view_definition,
schema_map_definition);
END_TYPE;
TYPE type_or_rule = SELECT
(named_type,
global_rule);
END_TYPE;
TYPE underlying_type = SELECT
(simple_type,
aggregation_type,
defined_type,
constructed_type);
END_TYPE;
(* not abstract because of generic aggregates *)
ENTITY aggregation_type
SUPERTYPE OF (ONEOF(variable_size_aggregation_type, array_type))
SUBTYPE OF (data_type);
element_type : data_type;
END_ENTITY;
ENTITY algorithm_declaration
ABSTRACT SUPERTYPE OF (ONEOF (function_declaration,
procedure_declaration))
SUBTYPE OF (declaration);
END_ENTITY;
ENTITY algorithm_definition
ABSTRACT SUPERTYPE OF (ONEOF (function_definition,
procedure_definition));
name : express_id;
parameters : LIST[0:?] OF parameter;
END_ENTITY; -- algorithm_definition
ENTITY andor_subtype_expression
SUBTYPE OF (subtype_expression);
END_ENTITY;
ENTITY and_subtype_expression
SUBTYPE OF (subtype_expression);
END_ENTITY;
ENTITY annotation
ABSTRACT SUPERTYPE OF (ONEOF (documentation, express_code));
target : documentation_object;
values : LIST [1:?] OF STRING;
END_ENTITY; -- annotation
(* OPTIONAL bounds only in the case of generic array *)
ENTITY array_type
SUBTYPE OF (aggregation_type);
lower_index : OPTIONAL bound;
upper_index : OPTIONAL bound;
unique_flag : BOOLEAN;
optional_flag : BOOLEAN;
END_ENTITY;
(* maybe also to introduce alias_attribute for EXPRESS_2 ?*)
ENTITY attribute
ABSTRACT SUPERTYPE OF
(ONEOF(derived_attribute,explicit_attribute,inverse_attribute,view_attribute
));
name : express_id;
parent_entity : entity_or_view_definition;
order : OPTIONAL INTEGER;
END_ENTITY;
ENTITY bag_type
SUBTYPE OF (variable_size_aggregation_type);
END_ENTITY;
ENTITY binary_type
SUBTYPE OF (simple_type);
width : OPTIONAL bound;
fixed_width : BOOLEAN;
END_ENTITY;
ENTITY boolean_type
SUBTYPE OF (simple_type);
END_ENTITY;
ENTITY bound
ABSTRACT SUPERTYPE OF
(ONEOF(integer_bound,population_dependent_bound));
END_ENTITY;
ENTITY constant_declaration
SUBTYPE OF (declaration);
END_ENTITY;
ENTITY constant_definition;
name : express_id;
domain : base_type;
constant_value : base_type; -- should be ENTITY here
END_ENTITY;
(* not abstract since it can be used for GENERIC *)
ENTITY data_type
SUPERTYPE OF
(ONEOF(named_type, enumeration_type, select_type, simple_type,
aggregation_type));
name : express_id;
END_ENTITY;
ENTITY data_type_declaration
SUPERTYPE OF
(ONEOF(entity_declaration, type_declaration))
SUBTYPE OF (declaration);
END_ENTITY;
ENTITY declaration
ABSTRACT SUPERTYPE OF (ONEOF(interfaced_declaration, local_declaration)
AND ONEOF(data_type_declaration, rule_declaration,
algorithm_declaration, constant_declaration));
parent_schema : generic_schema_definition;
definition : declaration_type;
END_ENTITY;
ENTITY defined_type
SUBTYPE OF (named_type);
domain : underlying_type;
END_ENTITY;
ENTITY dependent_map_definition
SUBTYPE OF (map_definition);
END_ENTITY;
ENTITY dependent_view_definition
SUBTYPE OF (view_definition);
domain : OPTIONAL base_type;
END_ENTITY;
ENTITY derived_attribute
SUBTYPE OF (attribute);
domain : base_type;
redeclaring : OPTIONAL explicit_or_derived;
SELF\attribute.parent_entity : entity_definition;
END_ENTITY;
ENTITY documentation
SUBTYPE OF (annotation);
END_ENTITY; -- documentation
ENTITY domain_equivalent_type;
external_type : named_type;
native_type : named_type;
owner : external_schema;
END_ENTITY;
ENTITY entity_declaration
SUBTYPE OF (data_type_declaration);
SELF\declaration.parent_schema : schema_definition;
SELF\declaration.definition : entity_definition;
END_ENTITY;
ENTITY entity_definition
SUBTYPE OF (entity_or_view_definition);
complex : BOOLEAN;
instantiable : BOOLEAN;
independent : BOOLEAN;
SELF\entity_or_view_definition.supertypes : LIST [0:?] OF UNIQUE
entity_definition;
INVERSE
attributes : SET[0:?] OF attribute FOR parent_entity;
uniqueness_rules : SET[0:?] OF uniqueness_rule FOR parent_entity;
global_rules : SET[0:?] OF global_rule FOR entities;
END_ENTITY;
ENTITY entity_or_view_definition
ABSTRACT SUPERTYPE OF (ONEOF (entity_definition, view_definition))
SUBTYPE OF (named_type);
supertypes : LIST [0:?] OF UNIQUE entity_or_view_definition;
END_ENTITY;
ENTITY enumeration_type
SUBTYPE OF (data_type);
elements : LIST [1:?] OF UNIQUE express_id;
END_ENTITY;
ENTITY explicit_attribute
SUBTYPE OF (attribute);
domain : base_type;
redeclaring : OPTIONAL explicit_attribute;
optional_flag : BOOLEAN;
SELF\attribute.parent_entity : entity_definition;
END_ENTITY;
ENTITY express_code
SUBTYPE OF (annotation);
END_ENTITY;
ENTITY external_schema;
definition : schema_definition;
native_schema : schema_definition;
INVERSE
for_types : SET[1:?] OF domain_equivalent_type FOR owner;
END_ENTITY;
ENTITY function_declaration
SUBTYPE OF (algorithm_declaration);
END_ENTITY;
ENTITY function_definition
SUBTYPE OF (algorithm_definition);
return_type : data_type;
return_type_label : OPTIONAL express_id;
END_ENTITY; -- function_definition
ENTITY generic_schema_definition
ABSTRACT SUPERTYPE OF (ONEOF(schema_definition, schema_view_definition,
schema_map_definition));
name : express_id;
identification : OPTIONAL info_object_id;
UNIQUE
UR1: identification;
END_ENTITY;
ENTITY global_rule;
name : express_id;
entities : LIST [1:?] OF entity_definition;
INVERSE
where_rules : SET [1:?] OF where_rule FOR parent_item;
END_ENTITY;
ENTITY implicit_declaration
SUBTYPE OF (interfaced_declaration);
END_ENTITY;
ENTITY independent_view_definition
SUBTYPE OF (view_definition);
END_ENTITY;
ENTITY integer_bound
SUBTYPE OF (bound);
bound_value : INTEGER;
END_ENTITY;
ENTITY integer_type
SUBTYPE OF (simple_type);
END_ENTITY;
ENTITY interfaced_declaration
ABSTRACT SUPERTYPE OF
(ONEOF(implicit_declaration, used_declaration, referenced_declaration))
SUBTYPE OF (declaration);
alias_name : OPTIONAL express_id;
END_ENTITY;
ENTITY inverse_attribute
SUBTYPE OF (attribute);
domain : entity_definition;
redeclaring : OPTIONAL inverse_attribute;
inverted_attr : explicit_attribute;
min_cardinality : OPTIONAL bound;
max_cardinality : OPTIONAL bound;
duplicates : BOOLEAN;
SELF\attribute.parent_entity : entity_definition;
END_ENTITY;
ENTITY list_type
SUBTYPE OF (variable_size_aggregation_type);
unique_flag : BOOLEAN;
END_ENTITY;
ENTITY local_declaration
SUBTYPE OF (declaration);
END_ENTITY;
ENTITY logical_type
SUBTYPE OF (simple_type);
END_ENTITY;
ENTITY map_declaration
SUBTYPE OF (data_type_declaration);
SELF\declaration.parent_schema : schema_map_definition;
SELF\declaration.definition : map_definition;
END_ENTITY;
ENTITY map_definition;
name : express_id;
END_ENTITY;
ENTITY map_partition;
parent : map_definition;
name : express_id;
END_ENTITY;
ENTITY named_type
ABSTRACT SUPERTYPE OF (ONEOF(defined_type, entity_definition))
SUBTYPE OF (data_type);
short_name : OPTIONAL STRING;
INVERSE
where_rules : SET [0:?] OF where_rule FOR parent_item;
END_ENTITY;
ENTITY number_type
SUBTYPE OF (simple_type);
END_ENTITY;
ENTITY oneof_subtype_expression
SUBTYPE OF (subtype_expression);
END_ENTITY;
ENTITY parameter;
name : express_id;
parameter_type : data_type;
var_type : BOOLEAN;
(* type labels may occur nested, e.g. X and Y in 'AGGREGATE:X OF
GENERIC:Y' *)
type_labels: OPTIONAL LIST [1:?] OF express_id;
END_ENTITY;
ENTITY population_dependent_bound
SUBTYPE OF (bound);
END_ENTITY;
ENTITY procedure_declaration
SUBTYPE OF (algorithm_declaration);
END_ENTITY;
ENTITY procedure_definition
SUBTYPE OF (algorithm_definition);
END_ENTITY; -- procedure_definition
ENTITY real_type
SUBTYPE OF (simple_type);
precision : OPTIONAL bound;
END_ENTITY;
ENTITY referenced_declaration
SUBTYPE OF (interfaced_declaration);
END_ENTITY;
ENTITY rule_declaration
SUBTYPE OF (declaration);
END_ENTITY;
ENTITY schema_definition
SUBTYPE OF (generic_schema_definition);
INVERSE
entity_declarations : SET[0:?] OF entity_declaration FOR parent_schema;
type_declarations : SET[0:?] OF type_declaration FOR parent_schema;
rule_declarations : SET[0:?] OF rule_declaration FOR parent_schema;
algorithm_declarations : SET[0:?] OF algorithm_declaration FOR
parent_schema;
external_schemas : SET[1:?] OF external_schema FOR native_schema;
END_ENTITY;
ENTITY schema_map_definition
SUBTYPE OF (generic_schema_definition);
INVERSE
view_declarations : SET[0:?] OF view_declaration FOR parent_schema;
map_declarations : SET[0:?] OF map_declaration FOR parent_schema;
END_ENTITY;
ENTITY schema_view_definition
SUBTYPE OF (generic_schema_definition);
INVERSE
view_declarations : SET[0:?] OF view_declaration FOR parent_schema;
END_ENTITY;
ENTITY select_type
SUBTYPE OF (data_type);
selections : SET [1:?] OF named_type;
END_ENTITY;
ENTITY set_type
SUBTYPE OF (variable_size_aggregation_type);
END_ENTITY;
ENTITY simple_type
ABSTRACT SUPERTYPE OF
(ONEOF(integer_type,number_type,real_type,boolean_type,logical_type,binary_t
ype,string_type))
SUBTYPE OF (data_type);
END_ENTITY;
ENTITY source_parameter;
name : express_id;
parent : map_or_view_select;
extent : entity_or_view_definition;
order : INTEGER;
END_ENTITY;
ENTITY string_type
SUBTYPE OF (simple_type);
width : OPTIONAL bound;
fixed_width : BOOLEAN;
END_ENTITY;
ENTITY subtype_constraint;
name : OPTIONAL express_id;
super_type : entity_or_view_definition;
constraint : subtype_expression;
END_ENTITY;
ENTITY subtype_expression ABSTRACT SUPERTYPE OF
(ONEOF (andor_subtype_expression, and_subtype_expression,
oneof_subtype_expression));
operands : SET [1:?] OF entity_or_view_or_subtype_expression;
END_ENTITY;
ENTITY target_parameter;
name : express_id;
parent : map_definition;
extent : entity_definition;
lower_bound : INTEGER;
upper_bound : OPTIONAL INTEGER;
order : INTEGER;
END_ENTITY;
ENTITY type_declaration
SUBTYPE OF (data_type_declaration);
SELF\declaration.parent_schema : schema_definition;
SELF\declaration.definition : defined_type;
END_ENTITY;
ENTITY uniqueness_rule;
label : OPTIONAL express_id;
attributes : LIST [1:?] OF attribute;
parent_entity : entity_definition;
END_ENTITY;
ENTITY used_declaration
SUBTYPE OF (interfaced_declaration);
END_ENTITY;
ENTITY variable_size_aggregation_type
ABSTRACT SUPERTYPE OF (ONEOF(bag_type,set_type,list_type))
SUBTYPE OF (aggregation_type);
lower_bound : OPTIONAL bound;
upper_bound : OPTIONAL bound;
END_ENTITY;
ENTITY view_attribute
SUBTYPE OF (attribute);
SELF\attribute.parent_entity : independent_view_definition;
END_ENTITY;
ENTITY view_declaration
SUBTYPE OF (data_type_declaration);
SELF\declaration.parent_schema : schema_map_or_view_definition;
SELF\declaration.definition : view_definition;
END_ENTITY;
ENTITY view_definition
ABSTRACT SUPERTYPE OF (ONEOF(independent_view_definition,
dependent_view_definition))
SUBTYPE OF (entity_or_view_definition);
SELF\entity_or_view_definition.supertypes : LIST [0:?] OF UNIQUE
entity_definition;
(*DERIVED
binding_extent : LIST [1:?] OF source_parameter;
*)
END_ENTITY;
(** If no partitions are explicitly defined we may assume an implicit
one *)
ENTITY view_partition;
parent : view_definition;
name : express_id;
END_ENTITY;
ENTITY view_partition_attribute;
parent_view_attribute : view_attribute;
related_partition : view_partition;
END_ENTITY;
ENTITY where_rule;
label : OPTIONAL express_id;
parent_item : type_or_rule;
order : INTEGER;
END_ENTITY;
END_SCHEMA;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.steptools.com/pipermail/wg11/attachments/20020220/2b9791a0/attachment.html
More information about the wg11
mailing list