The example for 'References to a Template Module' contains the line:
alias MyTemplModule2<S1, S2, m> MyTemplModule;

According to rule 193, 'MyTemplModule2' should be a scoped_name that refers to a previously defined Template Module. There is nothing else (successfully) defined as 'MyTemplModule2'. I think this line should be:

alias MyTemplModule<S1, S2, m> MyTemplModule2;

The IDL specification uses the term "simple template types" to refer to string, sequence, map, and fixed-point types. The reason being because they can be parameterized by the type of the element and/or length.

The first problem is that there are no "complex template types" anywhere in the spec so this "simple" term is confusing.

In addition to this, section 7.4.1.4.4.1 (Simple Types) provides the following definition:

Simple types are types whose definition more or less pre-exists to any IDL specification. They can be split in two categories:
• Basic types that basically represent numbers and characters and fully pre-exist any IDL specification.
• Simple template types whose generic definition pre-exists any IDL specification but need to be instantiated with parameters, to become actual types.

But later on it includes "sequences" as one of the "simple template types" . This may be OK for strings and fixed-point types as they are parameterized with just integer "lengths", or even sequences of primitive types. However this is not correct because soem sequences require prior definition of the underlying element type thus do not "pre-exists to any IDL specification".

Section 7.4.1.4.4.1.2 (Simple Template Types) provides the following definition:

Simple template types are template types whose generic definition pre-exists any IDL specification. To be used as an actual type, such a generic definition must be instantiated, i.e., given configuration parameters, whose nature depends on the template type.

Note that the categories "Simple Types" and "Simple Template Types" were introduced in IDL4. It was not present in IDL 3.5 and earlier.

These issues should be resolved.

Reorganize section 7.4.1.4.4.1 and provide more accurate definitions

Section 7.4.1.4.4.1 is not about declaring types but referencing types so it should be renamed to something like "Referencing Types" and the description changed accordingly. It should also be moved to be before 7.4.1.4.4 (Data Types).

The current subsections 7.4.1.4.4.1.1 (Basic Types ) and 7.4.1.4.4.1.2 (Simple Template Types) should be moved out to the same level.

The section "Simple Template Types" should e renamed "Template Types" and references to "simple template types" changed to "template types"

The definition of "template types" should be improved.

IDL uses the keywords short, long, and long long to designate integer types of sizes 16, 32, and 64 bits, respectively.

In IDL the size of these integer types is well specified. However these names confuse users familiar with languages such as C and C++ where the size of these integers is platform specific. As a result many users end-up defining their own typedefs for different size integers (e.g. INT16, or Int16) resulting in IDLs that are non-uniform do not leverage the built-in types.

To avoid this, IDL should follow the approach taken in C/C++ and introduce typedefs whose name unambiguously indicates the size of the representation.

Proposed "builtin typedefs" would be:

typedef               short              int16; 
typedef               unsigned short     uint16;
typedef               long               int32;
typedef               unsigned long      uint32;
typedef               long long          int64;
typedef               unsigned long long uint64;

Add new keywords for the integer types

Add new keywords for int16, int32, int64, uint16, uint32, and uint64. This should go in the "Building Block Extended Data Types" so that it does not impact existing applications.

The content "Scope" section appears to have been copied from the original RFC motivation. As a result it reads more as a "history" of the specification rather than defining the scope.

The history of how the specification came about is useful and should be stated somewhere. However the main focus of the scope section would be to define the boundaries and goals for the specification.

Rewrite Scope and move historical background text to section 6

Most of the current text in Section 1 "Scope" is about the history of the specification. This text should be moved to section 6 "Additional Information"

A paragraph describing the goals and boundaries for the IDL specification should be written and placed in section 1. "Scope"

The building blocks BB Templates, BB Annotations, BB Anonymous Types, and BB Extended Types are both basic (dealing just with data types) and general purpose (independent of platform CORBA, DDS, CCM).

They also have no dependencies on other building blocks other than the BB Core Data Types. Even if the BB Interfaces does not depend on them (i.e. some specification can comply with the BB Interfaces without complying wth the aforementioned modules), it is still possible to define interfaces that use these type extensions and annotations.

For this reason these should me moved to appear in the specification ahead of the BB Interfaces and platform- specific BBs.

The most natural place would be following the BB Core Data Types.

Reorder Building Blocks

Reorder building blocks, as suggested in the issue description.
The Building Blocks for Extended Data Types, Anonymous Types, Annotations, and Template Modules should be placed following the Building Block for "Core Data Types".

Extensibility Annotation

Section 8.3.1.6 defines the @extensibility annotation as follows:

@annotation extensibility {
    enum ExtensibilityKind {
        FINAL,
        APPEND,
        MUTABLE
    };
    ExtensibililtyKind value;
};

However, section 7.2.3 of DDS-XTYPES specifies that the types of extensibility and mutability are the following:

• FINAL
• APPENDABLE
• MUTABLE

For consistency, the IDL specification should use "APPENDABLE" instead of "APPEND".

Shortcut Annotations

In Section 8.3.1 the IDL specification defines the annotations @final as a shorcut for @extensibility(FINAL) (Section 8.3.1.7) and @mutable as a shortcut for and @extensibility(MUTABLE) (Section 8.3.1.8).

For consistency, the IDL specification should introduce @appendable as a shortcut for @extensibility(APPENDABLE).

Default Literal Annotation

DDS-XTYPES Section 7.3.1.2.1.10 (Default Literal for Enumeration) defines the annotation @default_literal as:

@annotation default_literal {};

This is a general purpose annotation that marks an element of an enumeration as the default one for that enumeration.

For consistency with similar generic annotations it should be added to IDL section 8.3.2 (Group of Annotations Data Modeling)

Modify annotations as suggested in issue description

Perform the suggested modifications

As of version 4.1, IDL lacks explicit support for 8-bit signed/unsigned integers. While, there are two data type with 1-byte size, these are not suitable for encoding 8-bit integers:

• char => 8-bit quantity that:
  • encodes a single-byte character from any byte-oriented code set, or
  • in an array, encodes a multi-byte character from a multi-byte code set
• octet => opaque 8-bit. guaranteed not to undergo any change by the middleware.

Unfortunately, reference programming languages don't have consistent behavior:

• Java: byte => signed 8-bit
• C#
  • byte => unsigned 8-bit
  • sbyte => signed 8 bit
• C (C90 and later)
  • char => unspecified. Compiler dependent (http://www.arm.linux.org.uk/docs/faqs/signedchar.php)
  • signed char => signed 8-bit number
  • unsigned char => unsigned 8-bit number
• C++
  • char => recommended for chars only. Allowed for numbers but unspecified sign
  • signed char => signed 8-bit number
  • unsigned char => unsigned 8-bit number

Other dialects of IDL provide support for 8-bit signed/unsigned integers as follows:

• MIDL (Microsoft's IDL)
  • Introduces the small keyword to represent 8-bit integers (see MIDL documentation). Additionally, it uses the hyper keyword to represent 64-bit integers (i.e., a long long in OMG IDL).
  • The integer types in MIDL are:
    • [unsigned] small (8-bit integer)
    • [unsigned] short (16-bit integer)
    • [unsigned] long (32-bit integer)
    • [unsigned] hyper (64-bit integer)
  • This IDL dialect introduces also the signed keyword and therefore numeric values can be marked as signed or unsigned (if unspecified they default to signed).
  • Web IDL
    • Introduces byte keyword to represent a signed 8-bit integer and treats octets as an unsigned 8-bit integer (see documentation).
    • The integer types in Web IDL are:
      • byte (signed 8-bit integer)
      • octet (unsigned 8-bit integer)
      • [unsigned] short (16-bit integer)
      • [unsigned] long (32-bit integer)
      • [unsigned] long long (64-bit integer)
• XPIDL
  • Does not support signed 8-bit integers (see documentation)

Add support for 8-bit Integers

We have identified four possible candidate solutions listed below. See the end for the decision on the adopted solution.

1. Introduce a new keyword in IDL to indicate an 8-bit integer.

This would preserve the current semantic and mapping of octet (opaque, do not use it as a number). If we do this it would be like the other integers in IDL where it is signed unless we qualify it with "unsigned."

This solution has three alternatives depending on the keyword selected. We have considered byte, small, and tinyint:

Alternative 1.1: Add new byte keyword

byte  ==> signed 8-bit integer
unsigned byte  ==> unsigned 8-bit number

This approach is clean and consistent but we are concerned with using the keyword "byte" because of the ambiguity with the definitions in C# and Java. It also does not sound like a number. It sounds like "octet". In fact it means exactly that.

Alternative 1.2: Add new small keyword (following MIDL's model)

small  ==> signed 8-bit integer
unsigned small  ==> unsigned 8-bit number

Alternative 1.3: Add new tinyint keyword (following SQL model)

tinyint  ==> signed 8-bit integer
unsigned tinyint  ==> unsigned 8-bit number

*Alternative 1.4: Add new int8 and

keywords (following new C/C++ standard names)*

int8    ==> signed 8-bit integer
uint8  ==> unsigned 8-bit number

Solution 2: Use annotations on "octet" to indicate use as integer

This would mean that we could have "octet" type used three different ways:

octet                        -- current meaning (opaque 8-bit) not a number
@signed octet       -- signed 8-bit number
@unsigned octet  -- unsigned 8-bit number

This approach seems less clean than Approach 1 but it has the advantage of being less ambiguous and backwards compatible. Having said that, having both a keyword and an annotation called unsigned is a bit ambiguous. Also this would be the only use of the @unsigned annotation which is confusing. For example, someone may be tempted to use @unsigned short as a type.

Solution 3: Leverage the existing @bit_bound annotation

IDL4 says this about the @bit_bound annotation:

"it may be used to force a size, smaller than the default one to members of an enumeration or to integer elements."

So it seems if we used:

struct MyStruct {
     @bit_bound(8)  short             member1;
     @bit_bound(8)  unsigned short    member2;
};

The @bit_bound(8) would affect the serialization and also the language mapping.

For example in Java member1 could be typed as byte whereas member2 would be short in order to accommodate values between 128 and 255.

The advantage of Solution 3 is that it reuses the concepts already present without new keywords and annotations in a manner consistent with the intended purpose.

There are two alternative ways to do this:

Alternative 3.1
Just explain in the IDL 4 spec that this is the pattern used to model 8-bit integer types.

Alternative 3.2 (providing typedef for all integer types)

Expand the IDL 4 to define typedefs for all integer types making the size of the representation more obvious (similar to the new standard integer types in C99 and C++).

typedef @bit_bound(8) short              int8;
typedef @bit_bound(8) unsigned short     uint8;
typedef               short              int16; 
typedef               unsigned short     uint16;
typedef               long               int32;
typedef               unsigned long      uint32;
typedef               long long          int64;
typedef               unsigned long long uint64;

Solution 4: Allow the existing keyword "unsigned" to be used with octet

There are two alternative ways to implement this.

Alternative 4.1 Add also a signed keyword

Add signed as a keyword, which overcomes the ambiguity of solution (2). With the signed keyword, we could specify whether an octet (or a char) is signed or unsigned and follow C/C++ convention.

octet                   -- current meaning (opaque 8-bit) not a number
signed octet       -- signed 8-bit number
unsigned octet   -- unsigned 8-bit number

Alternative 4.2 Redefine “octet” to mean signed int

With this approach we would have:

Thus in C we would map IDL octet to C90 "signed char" and IDL "unsigned octet" to C90 unsigned char.

This mapping may break API portability with previous mappings, or break application code where the "char" was mapped to an unsigned value (e.g. in ARM processors).

To workaround it we could provide some way to prevent the mapping to "signed char". Maybe this is some command-line option to rtiddsgen, like "-nosignedchar"

Adopted solution

The chosen solution is 1 with alternative 4 (int8, uint8).
The reason to prefer introducing new keywords rather than relaying on annotations is that using an annotation (e.g. @bit_bound(8) opens the door for that annotation to be used in unexpected context and with un-expected parameters. For example the user could annotate not just a short, but also a long or long long. Or they could use a different value other than 8. All these cases would have to be described and handled resulting in more complexity for the user and tools. The "keyword" approach is simpler, more constrained, and better aligned with what the user expects.

The reason to choose int8 and uint8 is to align it with the resolution of IDL42-9. So we save having to add another keyword like "small
or "tiny" which would not be intuitive to the user.

This issue gathers a number of typographical error and grammatical improvements that woudl enhance the readability of the specification.

In section 8.3.3 (Group of Annotations: Units and Ranges) in the declaration of struct Foo it uses the keyword "Struct". It should be "struct" instead.

Section 2 (Conformance Criteria) edit the first sentence of the first paragraph as shown below:

This document defines IDL such that it can be referenced by for other specifications to reference and . It contains no independent conformance points.

Section 2 (Conformance Criteria) edit the 3rd sentence of the first paragraph as shown below:

However, the general organization of the clauses (by means of atomic building blocks and profiles that group them as detailed afterwards) is intended to ease conformance description and scoping.

Section 2 (Conformance Criteria) edit the bullets as shown below:

1. Future specifications that use Any future specification using IDL shall reference this IDL standard or a future revision thereof.
2. Future revisions of current specifications using that use IDL may reference this IDL standard or a future revision thereof.
3. Reference to this standard must shall result in a selection of building blocks possibly complemented by groups of annotations.
a. All selected building blocks shall must be supported entirely.
b. Selected annotations shall must be either supported as described in ‎8.2.2 Rules for Using Standardized Annotations, or fully ignored. In the latter case, the IDL-dependent using specification shall not define a specific annotation, either with the same name and another meaning or with the same meaning and another name.

Section 7.1 (Overview) edit the 2rd paragraph as shown below:
OMG IDL is a language that allows unambiguously specifying unambiguous specification of the
interfaces that client objects may use and (server) object implementations provide as well as all needed related constructs such as exceptions or and data types. Data types are needed to specify parameters and return value of interfaces' operations. They can be used also as first class constructs.

Section 7.1 (Overview) edit the 3rd paragraph as shown below:
IDL is a purely descriptive language. This means that invoking operations, implementing them or creating and accessing data actual programs that use these interfaces or create the associated data-types cannot be written in IDL, but in a programming language, for which mappings from IDL constructs have been defined. The mapping of an IDL construct constructs to a programming language construct will depend on the facilities available in the that programming language. For example, an IDL exception might be mapped to a structure in a language that has no notion of exception exceptions, or to an exception in a language that does. The binding of IDL constructs to several programming languages is described in separate specifications.

In Section 7.1 (Overview) edit the 4th paragraph as shown below:
A source file containing specifications written in IDL must shall have a ".idl" extension.

In Section 7.1 (Overview) edit the 5th paragraph as shown below:
The description of IDL grammar uses a syntax notation that is similar to Extended Backus-Naur Format (EBNF). However, to allow composition of specific parts of the description, while avoiding redundancy; a specific new operator (::+) has been added. This operator allows adding alternatives to an existing definition (assuming x ::= y, x ::+ z means actually x ::= y | z). For example, assuming the rule x ::= y, the rule x :: z shall be interpreted as x ::= y | z.

In Section 7.2.6.2.1 (Wide and Non-wide Characters) modify the last sentence as shown below:
Attempts to assign a wide character literal to a non-wide character constant, or to assign a non-wide character literal to a wide character constant, shall be treated as an error result in a compile-time diagnostic.

In Section 7.2.6.2.2 (Escape Sequences to Represent Character Literals) change the two occurrences of "must" to "shall" as shown below:
Nongraphic characters shall must be represented using escape sequences as defined below in Table ‎7 9. Note that escape sequences shall must be used to represent single quote and backslash characters in character literals.

In Section 7.4.1.1 (Purpose) edit the first paragraph as shown below:

This building block constitutes the core of any IDL specialization (all other building blocks assume that this one is included). It gathers all contains the syntax rules that allow defining most data types with what allows and the syntax rules that allow IDL basic structuring (i.e., modules). and, because Since it is the only mandatory building block which is mandatory, it also contains the root nonterminal <specification> for the grammar itself.

In Section 7.4.1.4.3 (Constants) first paragraph, change "must" to "shall" as shown below.
Well-formed constants must shall follow the following rules:

In Section 7.4.1.4.3 (Constants)
Perform edits changing:
"which must" to "which shall",
"rules are applied" to "rules shall be applied",
"are applicable" to "shall be applicable",
"are evaluated" to "shall be evaluated",
"are considered" to "shall be considered",
"are not considered" to "shall not be considered",
"is considered" to "shall be considered",
"are discarded" to "shall be discarded",
"are multiplied" to "shall be multiplied",
"is divided" to "shall be divided",
"are added" to "shall be added",
"is subtracted" to "shall be subtracted",

"is not performed" to "shall not be performed"
"can combine" to "may combine",
"using the imputed type" to "based on"
"If either argument is ... use" to "If either argument is ... it shall use"
"an error shall be flagged by the compiler" "it shall be treated as an error"
"shall be flagged as a compile time error" to "shall be treated as an error"
"shall cause a compile-time error" to "shall be treated as an error"

"has no effect" to "shall have no effect"

"should be shifted" to "shall be shifted"
"should be generated" to "shall be generated"

In section 7.4.1.4.4 (Data Types) Change "can" to "may" in the first sentence as shown below:
A data type can may be either a simple type or a constructed one. Those different kinds are detailed in the following clauses.

In section 7.4.1.4.4.1 (Simple Types) replace the first bullet:
• Basic types that basically represent numbers and characters and fully pre-exist any IDL specification.
With:
• Basic types representing primitive builtin types such as numbers and characters.

In the same section replace: "Those two categories" with "These two categories"

In the same section edit 3rd paragraph as shown below
Note – Within this building block, anonymous types, that is, types actual the type resulting from an instantiation of a template type cannot be used directly as is (anonymously). Instead, prior to any use, template types must it needs to be given a name through a typedef declaration prior to any use. Therefore, as expressed in the following rules, referring to a simple type can be done either using directly its name, if it is a basic type, or using through a scoped name, in all other cases:

In section 7.4.1.4.4.1.1 (Basic Types) Edit the first paragraph as shown below:
Basic types are pre-existing types that represent numbers or characters. The set of basic types is They are defined by the following rules:

In section 7.4.1.4.4.2.4 (Constructed Recursive Types and Forward Declarations) change the 3 occurences of the sentence
Compilers shall issue a diagnostic if this rule is violated.
With:
If this rule is violated it shall be treated as an error

In section 7.4.1.4.4.4 (Native Types) modify the second paragraph as shown below:
As stated in the following rules, declaring a native type consist in just is done prefixing the type name (<simple_declarator>) with the native keyword:

In section 7.4.2.4 (Explanations and Semantics) edit the second paragraph as shown below:
An any logically contains a value and some means that specifies to specify the actual type of the value. This means However, the specific way in which the actual type is defined is middleware-specific . Each IDL language mapping provides operations that allow ‎programmers to insert and access the value contained in an any as well as the actual type of that value.‎

In section 7.4.3.4.2 (Exceptions) change "is" with "shall be" as shown below:
If an exception is returned as the outcome to an operation invocation, then the value of the exception identifier is shall be accessible to the programmer for determining which particular exception was raised.

In the same section, 3rd paragraph, change "will" with "shall be" ab "is" with "shall be" as shown below:
If an exception is declared with members, a programmer shall be will be able to access the values of those members when such an exception is raised. If no members are specified, no additional information shall be is accessible when such an exception is raised.

In the same section, last paragraph, remove the word "thereafter"

In section 7.4.3.4.3 (Interfaces) modify the last sentence of the 2nd paragraph as shown:
An interface may also be declared with no definition with using a forward declaration (<interface_forward_dcl>).

In section 7.4.3.4.3.1 (Interface Header) modify the last paragraph as shown below:
A parameter or structure member which is of an interface type is actually semantically as a reference to an object implementing that interface. Each language binding describes how the programmer must represent such interface references.

In section 7.4.3.4.3.3 (Interface Body) modify the first paragraph as shown below:
As stated in the following rules, within an interface body, can be defined operations and attributes can be defined. Those constructs are defined in the scope of the interface and exported (i.e., accessible outside the interface definition using through their name scoped by the interface name).

In section 7.4.3.4.3.3.1 (Operations) replace "must" with "shall" in:
Operations that do not return a result shall must specify void as return type.
In the same section edit the paragraph below as shown:
The absence of a raises expression on an operation implies that there are no operation-specific exceptions. Invocations of such an operation may are still liable to receive raise one of the middleware-specific standard exceptions.

In section 7.4.3.4.3.3.2 (Attributes) replace "can" with "may" in the first sentence as shown:
Attributes may can also be declared within an interface.

In the same section edit the bullet below as shown:
• For plain attributes, raises expressions allow to indicate which of the potential user-defined exceptions may be raised are when the attribute is read (getraises) and which the ones are when the attribute is written (setraises). A plain attribute may have a getraises expression, a setraises expression or both of them. In the latter case, the getraises expression must be declared in first place.

In the same section edit the paragraph below as shown:
The absence of a raises expression (raises, getraises or setraises) on an attribute implies that there are no attribute-specific exceptions. Accesses to such an attribute may are still raise liable to receive middleware-specific standard exceptions.

In section 7.4.4.4 (Explanations and Semantics) modify the 1st paragraph as shown below:
This building block adds the possibility to embed inside an interface declaration, declarations of types, constants and exceptions inside an interface declaration.

In the same section modify the paragraph as shown below:
All those elements are exported (i.e., visible under the scope of their enclosing hosting interface). In contrast As opposed to attributes and operations, they may be redefined in a derived interface, which has the following consequences:

In the same section modify the last sentence in the paragraph as shown below:
An attempt to use an ambiguous name without qualification produces a compilation shall be treated as an error.

In section 7.4.5.1 (Purpose) modify the 2nd paragraph as shown below:
In contrast As opposed to interfaces which are merely groups of operations , values carry also state contents. A value type is, in some sense, half way between a "regular" IDL interface type and a structure.

In the same section modify the second bullet as shown below:
• Supports a single Single interface support.

In section 7.4.5.4.1.3.1 (State Members) modify the last sentence in the first paragraph as shown below:
While its public part is exposed to all, the private part of the state is only accessible to the implementation code and the marshaling routines.

In section 7.4.5.4.2 (Forward Declarations) modify the first sentence in the first paragraph as shown below:
Similar to Like interfaces, value types may be forward-declared, with the following syntax:

In section 7.4.9.4 (Explanations and Semantics) change "must" to "shall" in teh first bullet as shown below:
• A home declaration must shall specify exactly one component type that it manages. Multiple homes may manage the same component type.

In section 7.4.12.1 (Purpose) modify the first paragraph as shown:
The purpose of this building block is to allow embedding constructs in template modules. Template modules may be parameterized by a variety of parameters (called formal parameters), which by transition transitively makes all the embedded constructs parameterized by the same parameters. Before using it, a template module needs to be instantiated with values suited for the formal parameters. A template module instantiation results in a de facto instantiation of all its Instantiation of the template module instantiates all the embedded constructs.

In section 7.4.15.4.1 (Defining Annotations) edit the last two notes as shown below:
Note – Annotations may be user-defined, using this syntax. They can also be implicitly defined by the IDL-processing tools a compiler. In the latter case, the behavior should be as if the related definitions were included at the beginning of the IDL specification.

Note – Annotations should not cause more compile IDL-processing errors than strictly needed. Therefore, in case of multiple definitions of the same annotation in one IDL specification , the the IDL-processing tools compiler should accept them, provided that they are consistent. In contrast, malformed definitions shall be treated as an error In return, compilers should raise an error in case of malformed definitions.

In section 7.4.15.4.2 (Applying Annotations) modify the first bullet as shown below:
• The annotation name (<scoped_name>) prefixed with the at symbol commercial at (@), also known as commercial at.

In the same section modify the second note as shown below:
Note – Annotations should not cause more compile IDL-processing errors than strictly needed. Therefore, in case an unknown annotation is encountered, it should be simply ignored by the IDL-processing tools compiler. In contrast, malformed definitions shall be treated as an error In return, compilers should raise an error in case of malformed annotations.

In section 7.5.1 (Qualified Names) modify the last paragraph as shown below:
The declaration of attribute Title in interface C is ambiguous, since the compiler IDL-processor does not know which string_t is desired. Ambiguous declarations shall be treated as yield compilation errors.

In section 8.2.2 (Rules for Using Standardized Annotations) modify the bullets as shown below:
• Shall Must respect totally the standardized annotation syntax.

• May clarify the actual meaning of the annotation in the specific targeted context. That actual meaning may be more precise than, but shall must remain compliant with, the general one expressed here.

• Shall Must indicate the default behavior when no annotation is placed on an element that may be annotated. Note that this default is never identical to not the same as the default values defined provided for the annotation members (when these default values exist). This is because as the later values are just intended to be the most logical values when the annotation is present.

Fix the typos and make the improvements suggested in the issue description.

Apply the changes suggested in the issue description.