The specification should allow application of annotations to:
declarations, members, function parameters, union discriminator, enumerator literals, typedefs, sequence parameter, array parameter.

Some examples:

struct SS {
    @MemberAnnotation(value)  MyType  m1;
};

emum EE {
    @Value(value)  Enum1;
};

union MyUnion switch ( @key long ) {
   case 1:
       @CaseMemberAnn MT1 m1;
   defalt:
       long l;
};
struct SS {
    @shared sequence< MyType, 3>   m1;
    sequence<@shared  MyType, 3>   m1;

    @shared MyType m1[3];
    MyType @shared m1[3];

    @shared MyMatrix mm[3][4];
    MyMatrix @shared mm[3][4];
};


typedef MyType @shared MyTypeArray3[3];
typedef @shared MyType MyTypeArray3[3];

Clarify application rules for annotations

An annotation can be placed on any IDL constructs or sub-constructs.
Stating that in the grammar rules complicates dramatically all the rules and creates a dependency issue between building-blocks.
The proposed solution is therefore:

1. to remove from the grammar any reference towards where annotations can be placed – cf. rule (202), as it wrongly gave the impression that annotations could only be placed on first-level definitions.
2. to state more clearly in the text that annotations can be placed on any IDL constructs and sub-constructs.

(Note that the format for applying annotation remains defined by EBNF rules as it was).

TITLE:

The IDL4 spec syntax for bitsets departed from the one used in DDS-XTYPES.

DESCRIPTION:

In DDS XTYPES a bitset is defined like an enumeration with some extra annotations. For example:

@BitSet @BitBound(16)

     enum MyBitSet {

       FLAG_0,

       FLAG_1,

       @Value(7) FLAG_7

       @Value(15) FLAG_LAST

};

This defined the total number of bits in the bitset (16) as well provided symbolic names for the bits (FLAG_0), ... It also allowed the bit assignment to be defaulted (e.g. FLAG_0, FLAG_1) or explicitly assigned.

It is unclear how to do this in IDL4.

On the one hand one could write

struct MyBitSet {

    bitset<1> FLAG_0;

    bitset<1> FLAG_1;

    bitset<1> FLAG_7

    bitset<1> FLAG_LAST;

};

This would indicate each flag uses one bit. But it would not constrain the size of the overall bitset, nor the bit values for the flags.

One could also say:

struct MyBitSet {

    bitset<1, 16> FLAG_0;

    bitset<1, 16> FLAG_1;

    bitset<1, 16> FLAG_7

    bitset<1, 16> FLAG_LAST;

};

According to 7.2.8.6.3.2 the second integer would specify that the representation should use a 16-bit integer. But nowhere it is stated that all these will be reusing the same 16-bit integer...

Also bitsets can appear inside other structures as in (see 7.2.8.6.3.2):

struct MyStruct {

            bitset<1>        foo1;

            bitset<3>        foo2;

            bitset<4>        foo3;

            long                 anotherMember;

            bitset<1>        bar1;

            bitset<1>        bar2;

};

Where it is stated that bitsets that appear sequentially should be put together. This seems non-intuitive and brittle... In fact the spec recommends not to mix bitsets with other types for readability...

This syntax seems a bit arbitrary and also hard to process by IDL compiler. The XTYPES approach was simpler. If the goal was to avoid "re-purposing" the "enum" then IDL4 could have defined a new keyword, but yet use similar syntax/approach as XTYPES as in:

@bound(16) 

bitset {

    @value(0) FLAG_0;

    @value(1) FLAG_1;

    @value(7) FLAG_7;

    @value(15) FLAG_LAST;

};

 

// OR

@bound(16) 

bitset {

    FLAG_0 = 0;

    FLAG_1 = 1;

    FLAG_7 = 7;

    FLAG_LAST = 15;

};

This is less ambiguous as it separates clearly the size of the bitset from the actual flags-names used for each bit. It also allows the user to not bother assigning explicit values to each bit. Finally the syntax is closer to that of enumeration so it is much easier for IDL parsers to handle it.

Redesign of bitsets

In the previous version of IDL4, bit sets were created to serve two main purposes in a single construct, namely::

• Bit fields (à la C/C++)
• Named accesses to individual bits (as in XTypes)

Rationale for that "all-in-one" approach was to avoid introducing too many new IDL keywords. However, the result was deemed difficult to understand and to implement (notably because a struct had then different meanings and implementation depending if it contains or not bit fields) and not fully compliant with what was designed in XTypes.

The proposal is thus to separate those two things and to design accordingly two different constructs.
The consequence is that it introduces 2 new keywords (bitfield and bitmask) in addition to the existing one (bitset), which is not that annoying as they should not collide too often with existing identifiers (and if they do, IDL provides a mechanism to mitigate the collision).

Supporting empty structures is desired to facilitate the mapping from other data-models that may contain them. In addition the type system in XTYPES already supports them but it is not possible to express it in IDL.

We have found many practical situations where people create empty structures. It may be used these are temporary place holders. Or they can be used as markers for specialized classes that represent different types all inheriting from a common base class.

In all these cases when going to IDL it becomes necessary to add a dummy member like:

struct MyEmptyStruct {
    octet __dummy_member;
};

Note that C and C++ support empty structures. So this should not create problems in the language mappings.

Change <struct_def> in BB Extended Data-types

In BB Extended Data-types, structure definition is already modified to support single inheritance (cf. rule (195)). Complement that extension with the ability of defining void structures.

We’re trying to implement a simple parser based on a subset of the IDL 4.0 BBs, and we’re coming across a number of oversights/mistakes in the language definition. For example, template module instances are required to end with two semicolons.

Invalid:
Typed<FOO> BAR;

Valid:
Typed<FOO> BAR;;

Rule 184 requires a semicolon after a template_module_inst:
(184) <definition> ::+ <template_module_dcl> ";"

Rule 194 defines template_module_inst as ending with a semicolon:
(190) <template_module_inst> ::= "module" <scoped_name> "<" <actual_parameters> ">" <identifier> ";"

There were one or two additional ones that I submitted through the OMG issue process, but never received the customary note from Juergen that it had been received. (unless it went to spam).

I’ll have to dig through my email for specifics of the other, but I believe it was:

Invalid:

struct foo

Valid

struct foo

Invalid:

struct foo

At the moment, we are proceeding under the assumption that such errors are fixed with the intuitive solution in each case, e.g., correct the grammar to allow similar behavior in such cases to IDL 3.5.

I’d like to make sure that our internal resolutions are correct before we invest too much time going down this rabbit hole.

Remove the extra ";" from rule (190)

This is an obvious mistake (the general strategy is that all the ending ";" are specified when adding items to <definition>).
The solution is just to remove that supernumerary piece at the end of rule (190).

In section 7.4.1.4.4.1 Simple Types, section on Char Types the paragraph that follows is redundant with what is already explained in other sections and moreover does not apply to the section. This causes confusion and therefore it should be removed.

The ISO Latin-1 (8859-1) character set standard defines the meaning and representation of all possible graphic characters used in IDL (i.e., the space, alphabetic, digit, and graphic characters defined in Table 7-2 on page 15, Table 7-3 on page 16 and Table 7-4 on page 16). The meaning and representation of the null and formatting characters (see Table 7-5 on page 18) is the numerical value of the character as defined in the ASCII (ISO 646) standard. The meaning of all other characters is implementation-dependent.

Suppress the unnecessary paragrap in section 7.4.1.4.4.1.3

This paragraph overspecifies what is a char. It should be removed.
Note that there is not such a paragraph for wchar.

Consider the following from the standard, which defines a struct:

```
(45) <struct_dcl> ::= <struct_def> | <struct_forward_dcl>
(46) <struct_def> ::= "struct" <identifier> "

"
(47) <member> ::= <type_spec> <declarators> ";"
(67) <declarators> ::= <declarator>

*
```

then all thee above are valid. Is this intended?

Also, rules 65 and 124 appear to suffer the same deficiency:

```
(65) <any_declarators> ::= <any_declarator>

(124) <context_expr> ::= "context" "(" <string_literal>

")"
```

Add the missing '' in the rules 65,67 and 124*

This is just typos resulting from an unfortunate cut and paste.

Rules 65, 67 and 124 should be:
(65) <any_declarators> ::= <any_declarator>

*
(67) <declarators> ::= <declarator>

*
(124) ‎<context_expr>‎ ‎::=‎ ‎"context" "(" <string_literal>

* ")"‎

Nothing else has to be changed in the specification.

<declarators> is defined as <declarator>

*
<any_declarators> := <any_declarator>

*

This better aligns with IDL 3.5 and likely the intention of the standard

Same issue as #1

Mistakes already reported in issue #1

Currently maps are defined to be parameterized only by "simple types". This means that anonymous types cannot be provided even if they are supported in the profile.
This is not consistent with sequence definition where anonymous types can be used (provided that BB Anoymous Types be part of the profile)
=> In rule (198), <simple_type_spec> should be replaced with <type_spec>

Change <simple_type_spec> to <type_spec> in map definition

With this modification, maps will accept anonymous types in parameters (provided that BB Anonymous Types is included)
This is more consistent with sequences (as said in the text).

Currently the default size of a bitmask is 64.
32 is actually used much more often and would be a more suitable default value

Set default value of bitmask size to 32

Amend resolution of issue #5 to set 32 as default value for a bitmask size, instead of 64.