I believe “| <op_with_context> ";"“ is missing from 7.4.6.4.1 and Annex A, which shows
(112) <export> ::+ <type_id_dcl> ";"

Reasoning:
7.4.6.3 shows:
(112) <export> ::+ <type_id_dcl> ";"

which if further confirmed in 7.4.6.4 which states that “Operations with Context“ is added by the CORBA-Specific Interfaces building block.

The

IDL 4.0 contained specific grammar rules for where annotations can be applied. Issue IDL41-9 revised these rules and left the spec with the general statement that (7.4.15.4.2): "An annotation may be applied to any IDL constructs or sub-constructs."

This is problematic for the following reasons:

• The phrase "under annotation" is used in multiple places in the spec without it being defined
• Tool implementors using a grammar based on the one in the spec need to make their own enhanced grammar to include <annotation_appl>, which undermines the usefulness of having a grammar in the spec
• Documentation of specific annotations (whether standardized in IDL, standardized in other OMG documents such as XTYPES, or non-standard) has no systemic way of describing where the annotation should be used
• Users have little assurance that their IDL will be understood by all conforming tools, even when using standardized annotations

The spec doesn't describe exactly to which element types @optional should be possible, leaving it to the vendor implementation. The spec should describe to which element type this annotation (but also the others) should be applied, struct members sounds logical, but what about union members, attributes, exception members?

The spec defines that a bitfield can be a maximum of 64bits, but it doesn't say anything about the maximum size of the bitset, can we create a bitset with 1000 fields of each 64bits? Is that legal, or is there some limit to the maximum size of a bitset

CORBA already have 'ami' as a keyword. I it does not need the @ami annotation.

DDS-RPC implements asynchronous methods as part of the API. It does not depend how the IDL interface was defined. So it does not need the @ami annotation or keyword in the interface.

The proposal is to remove the @ami annotation since neither DDS or CORBA need it. We will keep the ami keyword as it is.

The spec says "An annotation may be applied to any IDL constructs or sub-constructs. Applying an annotation consists actually in adding the related meta-data to the element under annotation." However, there is no definition of "IDL construct" or "IDL sub-construct". Furthermore, the nonterminal <annotation_appl> does not appear on the right-hand side of any grammar rule. Thus it is not formally specified where <annotation_appl> may appear in an IDL file.

The specification says "[...] a constant expression (<const_expr>) matching (or automatically castable) to, the defined type
of the discriminator." but "automatically castable to" is never defined. This is also the only place in the specification in which the word "cast" appears.

For all c++ code in this chapter the destructor should be override, not virtual

The raise operation should be _raise, that way any derived user exception can have a raise member, similar to _name and _rep_id. Looks an oversight when adding the code from TAOX11, we use _raise always there

The spec clearly specifies that when a union has an explicit default member, then this member should be chosen in its default constructor. When this is not the case, it would pick the first available case that is listed for its first available member.
However, it makes sense that if there is an implicit default member, then it is picked by the default constructor for the union.
Finally, it should be stated that you cannot overrule in any way what member the default constructor of a union will pick by using the @default annotation on any specific member,

The spec is not clear where optional may be applied, I wanted to use it with a typedef, see the test below, but it seems DDS XTypes disallowed it but IDL4 does seem to allow it, it says "This annotation may be used to set optionality on any element that makes sense to be optional.", my example makes sense about it. The spec should be more precise where this annotation (and others) maybe used

module Test {
@optional
typedef long OptLongFoo;
struct Bar

;
};

There is nothing explained what the expected behavior is when an annotation is applied at multiple levels, for example see the changed example from 8.3.3, what is the range for Foo:bar2, is it min=10,max=20 or min=5,max=10

@range (min=10, max=20)
typedef long MyLong;
...
struct Foo

;

The spec is silent about the relationship between min/max/range annotations and the default value. When I have an unsigned long and define min=10/max=20, is that legal without specifying a default value annotation? The default of an unsigned long is zero, so what should be generated in the code now as default? Or should the spec say that when min/max/range are used and the default value of the type is not in the range of those default should be specified by the user?

Section 8.3.3
Has the normative example;

@range (min=10, max=20)
typedef long MyLong;

It is unclear to me if the annotation applies to the typedef keyword or to the type in the typedef definition.

Some text for the annotations refers to element, but the introduction in 8.3.1 says "They may be applied on almost all kinds of elements", but what is an element. It looks for example logical that optional/value/min/max/unit/range can also be applied to a typedef, for example "@optional typedef boolean opt_bool1;". In a DDS world these annotations are mostly only used for types, but with CORBA/LwCCM adding them to a typedef could also mean that for example a optional is passed with a method call.

The spec should be more precise whether applying annotations to a typedef is legal.

It is unclear whether or how annotations such as "unit" and "range" apply to the values in an array or sequence. Other annotations may have similar ambiguity.

Do they apply to each contained value, or do do they somehow apply to the aggregate value? What about multi-dimensional arrays or nested sequences?

Does the range somehow apply to the sequence length, perhaps as a minimum?

Where do they belong in the array or sequence definitions – before the keyword, before the type name, or somewhere else?

Do the different locations accept different annotations? Do the annotations change meaning depending on location?

There are currently a number of numeric annotations presented in the spec. These are annotations that impact the numerical behavior of a type (like its allowed ranges). Right now, the spec doesn't clearly specify where these annotations may be applied and where they may not be applied. It would be wise to extend the section that introduces these annotations with a paragraph that clearly lays out these restrictions.

7.4.15.4.2 on p.101 contains the rule

(225) <annotation_appl> ::= "@" <scoped_name> [ "(" <annotation_appl_params> ")" ]

The nature of the EBNF notation leaves room for interpreting that between the @ and the <scoped_name> there could appear spaces, tabs, or even comments.

On the other hand, 7.4.15.4.1 on p.100 contains:

(220) <annotation_header> ::= "@annotation" <identifier>

Here, it is clear that @annotation shall be treated as a single token without intermittent characters between @ and annotation.

I propose adding a clarification in the explanations at the beginning of p.102 (following rule 227):

Applying an annotation consists in prefixing the element under annotation with:

• The annotation name ( <scoped_name> ) prefixed with the at symbol( @ ), also known as commercial at. There shall be no intermittent spaces, tabs, or comments between @ and <scoped_name>.

The last sentence is my proposed addition.

Should the IDL4 grammar specify that @value annotations, if specified for one enum field, MUST be used on all enum fields?
Regardless of whether we make this restriction, the specification should clearly state what happens when one field is annotated, but the next one is not.

Constructed types are types that are created by an IDL specification.

All types are created by an IDL specification, this is not a characterization that distinguishes constructed types.

I propose
     Constructed types are types that have members.

This would provide distinction from other types.

extensibility is heavily under specified in IDL4.2. It is listed as a general purpose annotation but it says nothing at the moment for the case appendable/mutable is specified and types are evolved. What are at that moment the rules for assignability/compatibility. Someone who just looks at IDL4 lacks a lot of required information

The specification is unclear of what the user can expect when using mutable and annotations like range, what when the old version of the type has a range of 1-10 and the new one range of 1-5. An old version is send with value 6, what does the receiver get? Very likely more annotations need to be extended in their description related to mutable

The specification just lists any as value for the min/max/default annotations, but that tells nothing about what is allowed as value, are for what about hex/octet values, floats, etc. Maybe make this more precise by referring to the value_expression rules `<const_expr>` as specified in 7.4.1.4.3 constants

Currently the key element type for maps is the same as the value element type, but that looks to be open, this allows for example a union, struct, reference, or other complex type as key type, all of them lack a comparison operator, very likely it is better to define a special map_key_type_spec just as we have for the union as switch_type_spec

The spec doesn't say anything about bitmask bit_value scoping. I think the spec currently allows

bitmask MyBitMask

;

This is problematic when a bitmask maps to an enum in C++. As a bitmask is pretty similar to an enum I do ask the following, in section 7.5.2 it says:

Enumeration value names are introduced into the enclosing scope and then are treated like any other declaration in that scope.

What about a bitvalue, shouldn't this also be done for a bitvalue (the members of a bitmask), that would allow a safe mapping to an enum in C++.

The spec should be clear about where bitmasks are introduced, within the bitmask scope itself, or in the enclosing scope

The spec says for bitfield " list of identifiers (<identifier>*).", shouldn't this be 1 or 0 identifiers, what if the user specifies 4 identifiers, how to separate them, what is the meaning?

As a OMG IDL user, I have messages that treat NaN or infinity as a significant value. I would like to specify this as a default for a field.

Currently, the OMG IDL specification says that a floating point value must include an integer part. It does not mention how to set or use special floating point values.

Per IEEE-754, there are a few types of NaN. It would be desirable for OMG DDS IDL to interpret NaN as a quiet NaN, which matches C++ and Python.

In ROS-IDL, it would look like this:
float32 float32_nan NaN
float64 float64_nan nan

In ROS 2, I proposed an implementation that sets NaN. In the IDL generator, it creates the following IDL file, which is not supposedly valid according to the standard:

module rosidl_generator_tests {
module msg {
module NanValueConstant_Constants

;
struct NanValueConstant

;
};
};

Can the specification be amended to support NaN, +inf, and -inf? This is blocking implementation in ROS 2.

Currently only TRUE or FALSE are allowed boolean values, but why not allow true and false (all lower case) as values

The annotation optional impacts the language mapping, for example in C it results in a pointer, with C++11 it could be a IDL::optional<>. The usage of an annotation is very weak in terms of semantics, it is much better to use a new optional keyword as optional heavily impacts the type presented to the programmer. Adding optional will break existing user code, it is not only something that is checked by a concrete middleware.

The IDL 4.2 page has a download link for the spec as published as an ISO: https://www.omg.org/spec/IDL/ISO/19516/PDF

All (?? - verification left as an exercise but there's 926 instances) the internal document links look to be screwy.

Search for e.g. "Reference source not found"

An example (from page 102):

Annex A
Consolidated IDL Grammar
This annex gathers all the rules from all the building blocks.
Error! Reference source not found.:
Error! Reference source not found. Error! Reference source not found.
Error! Reference source not found. Error! Reference source not found.
Error! Reference source not found. Error! Reference source not found.
... etc...

The data retrieval of described rules of constants entity during document compilation failed.

With a bitset/bitfield I assume you can use @default to specify a default value, would be nice if a binary constant could be used, as with C++, a binary constant consists of a sequence of ‘0’ and ‘1’ digits, prefixed by ‘0b’ or ‘0B’ for example 0b101010

IDL 4.2 says for bitset the following, but to our idea the IDL spec goes to far, how the data is organized in memory is something IDL can't enforce, probably not all programming languages provide such a direct way to control the memory layout. Middleware could control how a bitset is transferred on the wire, but I think IDL should not enforce the layout

Bit sets are sequences of bits stored optimally and organized in concatenated addressable pieces called bit fields,
themselves stored optimally. "Stored optimally" means that one bit uses just one bit in memory. "Concatenated" means
that each bit field will be placed in memory just after its predecessor within the bit set (no alignment considerations
apply).

I assume that in a map keys may not be unique (this should be added to 7.4.13.4.3.1), in case that is a restriction for a map, I propose to add a multimap which allows keys to be duplicate.

Now that with IDL4 the user can use @default to specify a specific default it would be good to also specify the default for all basic types when no @default is used. That way the user (or tool) can make a decision whether it must use @default in IDL or not

In the footnote the link to http://www.bipm.org/en/measurement-units/ is mentioned, but this seems to be dead, the link should probably be https://www.bipm.org/en/measurement-units/

Add ruby as language, there is a formal OMG language mapping for that, maybe just add all programming languages for which the OMG already has a formal language mapping

For int8 a new signed_type_int is defined, but I think it should just do the following so that anywhere where octet is used now int8 can be used

<octet_type> ::+ "int8",

IDL 4.2 syntax supports inheritance of only interfaces, valuetypes, and structures.

There are multiple scenarios where it would be useful to inherit other types, specifically Unions and Enumerations.

(1) Inheritance of unions

This would be very useful in some specs where unions are automatically generated. For example unions are created interface definitions in DDS-RPC and derived interfaces would like to use unions that "inherit" the unions in the base interfaces.

This would be useful when a "derived" union wants to add some more cases to the base union.

The derived union would have to use the same discriminator type. All it can do is add new discriminator cases that do not conflict with the non-default discriminator in the base union.

It can add a default case if not present in the base union.

Proposed syntax would be:

union DerivedUnion : BaseUnion {
    case 1 :
       Case1Type case1meber;
...
};

(2) Inheritance of enumerations

This is useful to add literals to an existing enumeration without touching the original definition.

The literals on the derived union would be constrained to not conflict the literals in the base class.

Proposed syntax would be:

enum DerivedEnum : BaseEnum {
    AdditionalLiteral1,
    ...
};

For bitmask the spec says "By default, the size of a bit mask is 32", but what unit is 32, I assume the spec wants to say "By default, the size of a bit mask is 32 bits"

All constructed types map to a C+11 class with accessors, but the new bitset mapping is an exception now, it delivers no accessor methods which gives a different API to the programmer. We propose to map to a class with accessors, similar like struct, or fastdds does in their implementation (see https://fast-dds.docs.eprosima.com/en/latest/fastddsgen/dataTypes/dataTypes.html#bitsets). Also the IDL inheritance is gone in C11, propose to use a derived class, so that in the C+11 code there is also an inheritance

There is a general need to document the IDL. However the IDL language does not provide any standard way to do this. As a consequence people may be forced to define custom annotations which would preclude the use across projects and/or development of general tools that are documentation aware.

To remediate this the suggestion is to add some built-in annotations that maybe used to document the IDL. For example the @documentation annotation below:

@annotation documentation {
    string value default "TBD";
};

This annotation could applied to a type declaration or to a member / element, as in:

@documentation("This documents the type Foo")
struct Foo {
    @documentation("documentation for member m1")
    long m1;
    @documentation("documentation for member m2")
    long m2;
 };

@documentation("This documents the type MyEnum")
enum MyEnum {
    @documentation("documentation for literal L1")
    L1,

    @documentation("documentation for literal L2")
    L2
 };

When map/bitset/bitmask are added it looks formal_parameter_type is not extended to allow these new types to be used as templated module arguments.

Section 7.4.13.4.3.1 defines IDL Maps but doesn't specify:

• Which types may be keys
• If maps need to de-duplicate equivalent entries
• If maps need to preserve order

The most essential of these is the first. It's currently unrestricted but this causes problems for language mappings where some additional operations (like less-than or equal-to) must be defined for these types. In order to prevent different language mappings adding different (conflicting) restrictions, the IDL spec should define this.

One approach to this would be that each building block should define how its types can (or can't) be used in maps. For example: everything in core data types is allowed; interfaces are not allowed; valuetypes are not allowed; etc.

The section Imports contains

The effects of an import statement are as follows:

• [...]
• Importing a name scope recursively imports all name scopes nested within it.

This looks counter intuitive to me.

Example:

module commontypes {
   module nested1 {
      enum RGBColor { RED, GREEN, BLUE };
   }
   module nested2 {
      enum TrafficLight { READ, YELLOW, GREEN };
   }
};

What happens if another module does "import commontypes"?

If, as the standard says, all name scopes nested within "commontypes" are recursively imported then this would lead to errors:
The enum values RED and GREEN would be directly visible and would be in conflict with each other.

The 'Group of Annotations General Purpose' includes the @autoid annotations which can optionally specify a HASH as in @autoid(HASH).

To be useful this must be augmented with the @hashid("MyString") annotation that allows an ID to be explicitly assigned by computing the hash of a string using the same algorithm that @autoid(HASH) uses.

Table 7-13 (Integer types) should have a little bit wider column 1 and the font size "See Building Block Extended Data" should match the other font in this table

Extend the grammar for Constants to allow constants for all Core Data Types that are currently not allowed:

• sequence
• structure
• union
• array

Section 7.4.1.4.4.4.4 Constructed Recursive Types and Forward Declarations (in the Core Data Types BB) has special semantic rules for sequences. The intent of Maps (in the Extended Data Types BB) seems to be that maps should have these same semantic rules.

There are a lot of more possibilities to be used with C++11 compared to C++, there is a specific OMG language mapping for C++11, so we would like to propose to add c++11 as defined value

Currently when we want to declare a type in a deeply nested module we have to start with all higher level modules, for example

module A {
module B {
module C

Since IDL is a specification language why have an IDL interface that cannot define data types it wishes to encapsulate and use as parameters for methods and attribute types? It looks like someone had a programming language in mind. I guess in the end the reason I think basic interfaces are a bad idea is that they can only be identified heuristically. The absence of contained types is a poor indicator of the IDL authors intent regarding whether the interface is basic or not.

Currently the specification says: Note – The default value (TRUE) is significant when the annotation is present (this means that using the compact form @nested will set the element as nested, which is what is expected intuitively). It does not mean that by default (i.e.,when no annotation is present) an element is nested.

The case when no nested is present should be specified, it should be the same as TRUE or FALSE and not left open. We observed that different DDS vendors take different decisions making portability of user IDL which uses partly @nested broken. Some vendors assume default nested TRUE, others FALSE which in practice means when the user wants portable IDL he has to specify it which each IDL type.

For the CORBA specifications as part of the scope chapter there are no hyperlinks, these should be added

Now that IDL is modular with building blocks, IDL authors need a way of guarding IDL files so they are compatible with tools that implement different subsets of the building blocks. See discussion in IDL43-21 for a motivating example.

See C++ feature test macros for a possible implementation pattern.
https://en.cppreference.com/w/cpp/feature_test

Another option is to have an "IDL_VERSION" macro that can be used as a pre-processor condition.

At present, annotation syntax must be placed in the IDL file, usually right before or after the syntax being annotated.

This works very well for annotations that define shared interface constraints. It does not work well for annotations that control internal implementation details, such as the selection of an API option. These internal details should be separated from the shared interface and so do not belong in the shared IDL file.

This proposal is to add a new syntax for annotating IDL structures. The basic idea is to define an annotation that takes two parameters, a "place" in the IDL and an annotation, and has the effect of inserting the annotation at the given place. For example @insert(Foo.x, @some(value)) would be equivalent to placing @some(value) by the definition of Foo.x.

With this mechanism, end users could create a custom IDL that includes the shared IDL and then adds the custom annotations.

7.4.13.4 "Explanations and Semantics" gives a synoptic list of the complements,

Those complements are:

• Additions to structure definition in order to support single inheritance and void content (no members).
• Ability to discriminate a union with other types (wide char and octet).
• An additional template type (maps).
• Additional constructed types (bitsets and bitmasks).

The complement "Integers restricted to holding 8 bits of information" (7.4.13.4.4) should be added there.

Predecessor: CPP1116-3

For mapping the switch of unions, the language mappings choose different fixed names.
It would be desirable to permit names that reflect the user's application domain.
Example:

  enum environment_t { air, water, land };

  @switchname("environment")
  union env_info_t switch (environment_t) {
    case air:
      air_info_t air_info;
    case water:
      [...]
  };

The @switchname annotation would cause the discriminator to be mapped using the given name.

This may replace the name chosen by the language mapping (such as in the Ada mapping), or it may supplement the mapping chosen name (such as in the C++ mapping), depending on the nature of the mapped union.

The provided name may not overlap with an enum value given in a case and it may also not overlap with a branch member name.

Currently the spec says:

The << binary operator indicates that the value of the left operand shall be shifted left the number of bits specified by the right operand, with 0 fill for the vacated bits. The right operand shall be in the range 0 <= right operand < 64.•The >> binary operator indicates that the value of the left operand shall be shifted right the number of bits specified by the right operand, with 0 fill for the vacated bits. The right operand shall be in the range 0 <= right operand < 64

But this should be more restricted, the range should be dependent on the number of bits of the underlying type, when it is for example a 32bit long, the operand should be in the range of 0 <= 32

IDL 4.2 allows the @value on an enum to set a specific value for example

enum Test_E

;

It would be more clear and logical when IDL would allow

enum Test_E

;

The use of the Omg.Types name should be changed to OMG.Types.

At the moment model generated IDL files are used it could happen that in a certain configuration setting an empty IDL module appears in an IDL file or when doing some prototyping the users uses an empty IDL file. Currently seciton 7.4.1.4.2 of the IDL specification requires an IDL module to have at least 1 definition. We propose to more relax this, to allow an empty IDL module.

Rule 3 should be changed to

<module_dcl> ::= "module" <identifier> "

" A module

And in the text

A list of at least one definition (<definition>+) enclosed within braces ({}). Those definitions form the module body.

Could be changed to

A list of zero or more definitions (<definition>*) enclosed within braces ({}). Those definitions form the module body

It is possible to put an annotation on an attribute with multiple declarators, like this:

struct Foo {
  @key long x, y;
};

What is the effect of this? Does the annotation apply to both declarators? In that case, how do you interpret the following:

struct Foo {
  @fieldid(0x01000) long x, y;
};

The spec should say how to handle this case.

Proposal - annotation applies to all declared members. In some cases this causes an error (same ID on 2 members). In other cases, tools could decide to issue warnings.

Structure inheritance is described by rules (45) and (48), page 27. The constraints on using forward-declared structures are given in section 7.4.1.4.4.4.4, page 40. For clarity, it would be better if this section made explicit the prohibited uses of forward declarations. This is done for value types in section 7.4.5.4.2 on page 57, "It is illegal to inherit from from a forward-declared value type not previously defined". Though this is a clarification it has been shown to be needed as this illegal use for forward-declared structures has occurred in external (to OMG) specifications that use IDL.

Programming languages that have the concept of modules/namespaces also include the concept of "using" a namespace type such that one can ommit the explicit reference to the 'used' namespace.

The following is an example for C++:

Assume the declaration:

namespace MyNamespace
{
    class MyClass
    {
    public:
        void my_operation() {}
    };
    void MyFunction1(MyClass) {}
}

Normally these types need to be accessed using their fully qualified names:

MyNamespace::MyClass obj;
obj.my_operation();
MyNamespace::MyFunction1(obj);

This can be cumbersome when having to reference a lot of types in the same namespace, specially for deep nested namespaces.

The C++ using declaration can bring the name space or individual types into scope simplifying the coding as in:

using MyNamespace::MyClass;
MyClass obj;
obj.my_operation();
MyFunction1(obj);

Or alternatively bringing every type in the name space into the scope:

using namespace MyNamespace;
MyClass obj;
obj.my_operation();
MyFunction1(obj);

Java and C# provide similar facilities:
In Java the "import" keyword is used to import packages or types into the scope. The syntax is:

import package.name.ClassName;   // To import a certain class only
import package.name.*;

In C# the "using" keyword is used to import namespaces or types into the scope. The syntax is:

using  MyNamespaceName.MyClassName;   // To import a certain class only
using MyNamespaceName;

This issue request that a similar facility is added to IDL

This was originally reported as https://issues.omg.org/browse/CORBA34-1

In 7.5.1, the 3rd bullet point lists "interface, struct, union, exception." Instead the same language from 7.5.2 ("The following kinds of definitions...") should be in effect.

In section 7.4.4.4.2 it is explained that an annotation may be used in a shortened form in the following conditions:

• There is no member or only one member with a default value.
  • In that it is allowed to apply the annotation by using just the annotation name.
• There is only one member.
  • In that case you may apply the name of the annotation and the value of its member, without explicitly mentioning the member name and the equals sign.

However, the second bullet may break backward compatibility when annotations get extended with additional members in future spec releases. Consider the following example:

@bit_bound(32)
bitmask DataRepresentationMask {
   @position(0) XCDR, 
   @position(1) XML,
   @posiiton(2) XCDR2
}

@annotation data_representation {
    DataRepresentationKind allowed_kinds;
};

Now to annotate an IDL type to support only the XCDR2 annotation, I can apply a shortened annotation like this:

@data_representation(XCDR | XCDR2)
struct Foo {
   long my_long;
};

Now suppose in a future version of the spec, we extend the @data_representation annotation with an additional field to specify the supported endianness, like this:

enum EndiannessKind {
    BIG_ENDIAN,
    LITTLE_ENDIAN,
    NATIVE_PLATFORM
};

@annotation data_representation {
    DataRepresentationKind allowed_kinds;
    EndiannessKind endianness;
};

In this case, the addition of the new member suddenly invalidates existing IDL files that use the shorthand notation.

What I want to propose is to allow the shorthand notation to be used for implicitly referring to the first available member. That is fully compatible with the current rule, but will also still apply when new members are added afterwards.

The grammar rule 195 (for struct_def) indicates that a structure may either inherit from a base or may be empty, but not both. The intent based on the text around the rule seems to be to allow structs that are both empty and inheriting.

8.3.3.1 "@default" and 8.3.6.2 "@oneway" specify standardized annotations that a user is not allowed to make use of because grammar rule 225 (in 7.4.15.4.2) states that a <scoped_name> is used to identify the applied annotation. From rule 4, a <scoped_name> is built out of <identifiers> which can't be keywords (see 7.2.1, 7.2.3, 7.2.4).

Section 7.4.11.4.3 on page 85 contains:

(181) <connector_inherit_spec> ::= ":" <scoped_name>

The rule number should be 182.

Page 112 top continues the bullet list started on p.111 bottom:

• May precise on which elements the annotation is valid in that specific context. That list may be only a subset of all the possible ones.

Replace "precise" by a verb, e.g. specify, detail, elaborate, or expound.

• Shall indicate the default behavior [...]. This is because the later values are intended to be the most logical values when the annotation is present.

"later" -> latter

In section 7.4.11.4.3 page 87 and in Annex A page 132, <connector_inherit_spec> should have the rule number 182.

7.2.6.2.1 on page 23 contains:

A character literal is one or more characters enclosed in single quotes, as in:
const char C1 = ’X’;

Please use the ASCII apostrophe:
const char C1 = 'X';

If an implementation wishes to claim support for the "Building Block Extended Data-Types", it must support all of its complements, including the section 7.4.13.4.4 "Integers restricted to holding 8-bits of information".

However, if the targeted programming language does not natively support int8 or uint8 then it is not obvious how the "unsupported" type may be mapped.

For example, the Java language has a native type byte which is signed.
The question then arises how the implementation maps the type uint8.

The implementation could choose to

• Maintain bit size:
  In that case, it would map uint8 to Java byte.
  The question then arises how values exceeding the positive signed maximum (127) are handled.
• Maintain numeric range:
  In that case, it could map uint8 e.g. to Java short (16 bit quantity) or int (32 bit quantity).
  The implementation must then address the interoperability with other languages where uint8 is
  mapped to an 8 bit quantity.
• Use yet a different mapping, for example a holder class (cf. Short, Integer, etc.)

I therefore propose adding the requirement that the implementation shall document its mapping choice:

If the targeted programming language does not natively support int8 or uint8 then an implementation
shall include information about how it maps the types which lack the native language support.

This is not an issue in the strict sense, just a usability observation.
If I copy/paste the word <porttype_def> of rule 174, it comes out as

>‎ yedeepyotrop <

In section 4 "Terms and Definitions" on page 7, the last sentence is:

> [...] Building blocks are described in
> clause 0,

The sentence seems to end on the comma; furthermore, I cannot find a "clause 0".

There is a stray > at the end of the title,

7.4.1.4.1 IDL Specification>

Page 133 last item of "From Building Block Extended Data-Types" :

(1) <unsigned_longlong_int> ::+ “uint64”

The rule number should be 215.

As an aside, the quotation marks used in rules 208 to 215 are fancy Unicode characters while the rest of the grammar uses the regular ASCII code 34 decimal.

The title of 7.4.13.4 says:

7.4.13.4 <unsigned_longlong_int> ::+ “uint64”Explanations and Semantics

This is a formatting error. The {{ <unsigned_longlong_int> ::+ “uint64”}} should appear before the title as one of the rules following:

(214) <unsigned_long_int> ::+ “uint32”

Note that this problem appears only in the generated PDF. The word document is fine.

Section 7.4.1.4.4.4.3 Enumerations says:

An enumeration must contain at least one enumerator and no more than 232.

The 232 is a typo. It was meant to be 2 ³²