| Previous | Table of Contents | Next |
This sub clause defines the standard Tags that apply to the Model to IDL mapping. Other Tags may be attached to the elements
of a meta-model, but the meaning of these Tags is not specified. Similarly, this sub clause does not specify the meaning of
the Tags below in contexts apart from the Model to IDL mapping.
All standard Tag identifiers for the IDL mapping start with the prefix string:
“org.omg.mof.idl_?
The notation used below for defining the Tags is described in Table 7.5 on page 137.
NOTE: Many of the IDL mapping Tags significantly alter the interface signatures of the generated IDL. It is prudent for an
IDL generator to only respect IDL mapping Tags when they are contained within the respective meta-model. Otherwise, it may
not be possible to determine which Tags were in effect when the meta-data server was generated. This would make it hard for
a client to infer the meaning of generated IDL at runtime. It would also make problems for automatic server and client generators.
This tag allows the meta-modeler to specify the CORBA Interface Repository Identifier prefix for the generated IDL. This is
essential when a MOF meta-model is used as the authoritative source for IDL for some other OMG standard.
tag id:attaches to:values:meaning: |
|||||
| “org.omg.mof.idl_prefix? | |||||
| Model::Package | |||||
| one String | |||||
| This tag supplies a RepositoryId prefix that is used for the entire module generated for the Package. |
tag id:idl generation:restrictions: |
|||||
| “org.omg.mof.idl_prefix? | |||||
| A #pragma prefix is inserted into the IDL before the “module? declaration for the Package. | |||||
| [1] A Prefix tag should only be attached to a non-nested Package. [2] A Prefix tag should have a value that is a valid OMG IDL prefix, consisting of ASCII letters, digits, underscore (‘_’), hyphen (‘-’) and period (‘.’) as specified in the CORBA Core specification. [3] A Prefix tag contained by a Package takes precedence over one that is not contained. |
When a MOF metamodel is modified it will often result in generated IDL that has the same module and interface names but different
interface signatures. In such cases, it is strictly necessary to use different IDL version numbers for all types, interfaces,
and exceptions whose signatures have changed. In MOF 1.4, this can be done by attaching an Version tag to the appropriate
model elements.
tag id:attaches to:values:meaning:idl generation:restrictions: |
|||||
| “org.omg.mof.idl_version? | |||||
| Model::Package, Model::Class, Model::Association, Model::Attribute, Model::Operation, Model::Reference, Model::StructureType, Model::AliasType, Model::CollectionType, Model::EnumerationType, Model::Exception, Model::Constant, Model::Constraint | |||||
| one String | |||||
| This tag supplies a version number that is used for selected IDL declarations corresponding to the tagged element. | |||||
| A #pragma version is inserted into or following selected IDL declaration for modules, interfaces, data types, constants, and exceptions generated from the tagged model element. Version tags on Attributes, Operations, and References result in version tags for the corresponding IDL operations. Refer to the respective templates for details. | |||||
| [1] A Version tag value must have the form “<major>.<minor>? where <major> and <minor> are unsigned 16 bit decimal integers. [2] It is not meaningful to attach a Version tag to an AssociationEnd, Import, Parameter, Tag, StructureField, or PrimitiveType. |
There are some situations when the IDL identifiers produced by the IDL mapping templates will result in name collisions. The
following tag allows a meta-modeler to provide a substitute for a model element’s name that will be used in IDL generation.
9.6.2.1 Substitute Name
tag id:attaches to:values:meaning:idl generation:restrictions: |
|||||
| “org.omg.mof.idl_substitute_name? | |||||
| Model::ModelElement | |||||
| one String | |||||
| The value is a name to be used in place of the model element’s name. | |||||
| Wherever the IDL mapping makes use of a model element’s name, the substitute name will be used in its place. This substitution occurs before the application of Format1, Format2, or Format3 rewriting and other name mangling. | |||||
| The preconditions described in “Preconditions for IDL Generation? on page 192 apply to the substitute name. For example: [1] The identifier formatting rules must produce a syntactically valid OMG IDL identifier from the value. [2] All identifiers produced from it must be unique in their respective scopes after formatting and name mangling, as per the IDL mapping specification. [3] There can be at most one Substitute Name tag for any given ModelElement. |
The following tags allow the meta-modeler to specify that a generated interface inherits from one or more additional IDL interfaces.
These tags allow the definition of MOF-based meta-models that are upwards compatible with pre-existing meta-data interfaces
expressed in CORBA IDL.
tag id:attaches to:values:meaning:idl generation:restrictions: |
|||||
| “org.omg.mof.idl_instance_supertypes? | |||||
| Model::Class | |||||
| one or more Strings (order is significant) | |||||
| The values give the fully qualified OMG IDL identifiers for additional interfaces that the “instance? interface for this Class should inherit from. | |||||
| The specified interfaces are added to the “instance? interface’s inheritance list following the other supertypes defined by the templates. They appear in the order given. | |||||
| [1] The values must be fully qualified identifiers for OMG IDL interfaces. [2] There can be at most one Instance Supertypes tag per Class. |
9.6.3.2 Instance Supertypes
tag id:attaches to:values:meaning:idl generation:restrictions: |
|||||
| “org.omg.mof.idl_instance_supertypes? | |||||
| Model::Class | |||||
| one or more Strings (order is significant) | |||||
| The values give the fully qualified OMG IDL identifiers for additional interfaces that the “instance? interface for this Class should inherit from. | |||||
| The specified interfaces are added to the “instance? interface’s inheritance list following the other supertypes defined by the templates. They appear in the order given. | |||||
| [1] The values must be fully qualified identifiers for OMG IDL interfaces. [2] There can be at most one Instance Supertypes tag per Class. |
9.6.3.3 Class Proxy Supertypes
tag id:attaches to:values:meaning:idl generation:restrictions: |
|||||
| “org.omg.mof.idl_class_proxy_supertypes? | |||||
| Model::Class | |||||
| one or more Strings (order is significant) | |||||
| The values give the fully qualified OMG IDL identifiers for additional interfaces that the “class proxy? interface for this Class should inherit from. | |||||
| The specified interfaces are added to the “class proxy? interface’s inheritance list following the other supertypes defined by the templates. They appear in the order given. | |||||
| [1] The values must be fully qualified identifiers for OMG IDL interfaces. [2] There can be at most one Class Proxy Supertypes tag per Class. |
9.6.3.4 Association Supertypes
tag id:attaches to:values:meaning:idl generation:restrictions: |
|||||
| “org.omg.mof.idl_association_supertypes? | |||||
| Model::Association | |||||
| One or more Strings (order is significant). | |||||
| The values give the fully qualified OMG IDL identifiers for additional interfaces that the interface for this Association should inherit from. | |||||
| The specified interfaces are added to the “association? interface’s inheritance list following the other supertypes defined by the templates. They appear in the order given. | |||||
| [1] The values must be fully qualified identifiers for OMG IDL interfaces. [2] There can be at most one Association Supertypes tag per Association. |
9.6.3.5 Package Supertypes
tag id:attaches to:values:meaning:idl generation:restrictions: |
|||||
| “org.omg.mof.idl_package_supertypes? | |||||
| Model::Package | |||||
| One or more Strings (order is significant). | |||||
| The values give the fully qualified OMG IDL identifiers for additional interfaces that the interface for this Package should inherit from. | |||||
| The specified interfaces are added to the “package? interface’s inheritance list following the other supertypes defined by the templates. They appear in the order given. | |||||
| [1] The values must be fully qualified identifiers for OMG IDL interfaces. [2] There can be at most one Package Supertypes tag per Package. |