1. OMG Mailing List
  2. IDL 4.3 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: idl43-rtf
  • Issues Count: 22

Issues Summary

Key Issue Reported Fixed Disposition Status
IDL43-27 Specify where annotations can be applied IDL 4.2 open
IDL43-32 Table formatting IDL 4.2 open
IDL43-31 Rules for Qualified Names need to take into account other Building Blocks IDL 4.2 open
IDL43-30 current IDL4 grammar breaks backward compatibility with respect to short hand notations IDL 4.2 open
IDL43-26 Some standardized annotations use keywords as identifiers IDL 4.2 open
IDL43-28 Extended structs that are both inheriting and empty IDL 4.2 open
IDL43-24 inheritance of unions and enumerations IDL 4.2 open
IDL43-25 Annotation @hashid should be added to 8.3.1 'Group of Annotations General Purpose' IDL 4.2 open
IDL43-23 Incorrect rule number on connector_inherit_spec IDL 4.2 open
IDL43-22 Typos in 8.2.2 enumerated list IDL 4.2b1 open
IDL43-12 Incorrect rule number on IDL 4.2b1 open
IDL43-11 Unicode apostrophe in source code IDL 4.2b1 open
IDL43-10 Mapping int8/uint8 in absence of target language native support IDL 4.2b1 open
IDL43-7 Apparently incomplete phrase IDL 4.2b1 open
IDL43-3 Typo in title of 7.4.1.4.1 IDL 4.2b1 open
IDL43-5 Typo in Annex A: Consolidated IDL Grammar IDL 4.2b1 open
IDL43-8 Copy/paste problem at IDL 4.2b1 open
IDL43-2 Formatting error in title of 7.4.13.4 IDL 4.2 open
IDL43-1 Typo in section 7.4.1.4.4.4.3 Enumerations IDL 4.2 open
IDL43-21 Constants for Core Data Types IDL 4.2b1 open
IDL43-9 Missing bullet "Integers restricted to holding 8 bits of information" IDL 4.2b1 open
IDL43-4 Syntax of annotation_appl requires clarification IDL 4.2b1 open

Issues Descriptions

Specify where annotations can be applied

  • Key: IDL43-27
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    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
  • Reported: IDL 4.2 — Wed, 5 Dec 2018 16:43 GMT
  • Updated: Tue, 12 Mar 2019 16:53 GMT

Table formatting

  • Key: IDL43-32
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: IDL 4.2 — Fri, 1 Mar 2019 10:07 GMT
  • Updated: Wed, 6 Mar 2019 14:55 GMT

Rules for Qualified Names need to take into account other Building Blocks

  • Key: IDL43-31
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    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.

  • Reported: IDL 4.2 — Thu, 14 Feb 2019 23:31 GMT
  • Updated: Thu, 14 Feb 2019 23:32 GMT

current IDL4 grammar breaks backward compatibility with respect to short hand notations

  • Key: IDL43-30
  • Status: open  
  • Source: ADLINK Technology Ltd ( Erik Hendriks)
  • Summary:

    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.

  • Reported: IDL 4.2 — Tue, 12 Feb 2019 16:31 GMT
  • Updated: Tue, 12 Feb 2019 16:33 GMT

Some standardized annotations use keywords as identifiers

  • Key: IDL43-26
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    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).

  • Reported: IDL 4.2 — Wed, 5 Dec 2018 00:00 GMT
  • Updated: Mon, 14 Jan 2019 14:26 GMT

Extended structs that are both inheriting and empty

  • Key: IDL43-28
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    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.

  • Reported: IDL 4.2 — Wed, 12 Dec 2018 22:20 GMT
  • Updated: Wed, 12 Dec 2018 22:20 GMT

inheritance of unions and enumerations

  • Key: IDL43-24
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    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,
        ...
    };
    
  • Reported: IDL 4.2 — Tue, 25 Sep 2018 19:31 GMT
  • Updated: Wed, 26 Sep 2018 09:15 GMT

Annotation @hashid should be added to 8.3.1 'Group of Annotations General Purpose'

  • Key: IDL43-25
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    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.

  • Reported: IDL 4.2 — Tue, 25 Sep 2018 21:53 GMT
  • Updated: Tue, 25 Sep 2018 21:53 GMT

Incorrect rule number on connector_inherit_spec

  • Key: IDL43-23
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    Section 7.4.11.4.3 on page 85 contains:

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

    The rule number should be 182.

  • Reported: IDL 4.2 — Sun, 1 Jul 2018 06:26 GMT
  • Updated: Tue, 7 Aug 2018 14:04 GMT

Typos in 8.2.2 enumerated list

  • Key: IDL43-22
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    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

  • Reported: IDL 4.2b1 — Sat, 17 Feb 2018 14:36 GMT
  • Updated: Fri, 6 Apr 2018 19:24 GMT

Incorrect rule number on

  • Key: IDL43-12
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

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

  • Reported: IDL 4.2b1 — Thu, 8 Feb 2018 21:22 GMT
  • Updated: Thu, 1 Mar 2018 00:28 GMT

Unicode apostrophe in source code

  • Key: IDL43-11
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    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';

  • Reported: IDL 4.2b1 — Sun, 4 Feb 2018 14:16 GMT
  • Updated: Thu, 1 Mar 2018 00:28 GMT

Mapping int8/uint8 in absence of target language native support

  • Key: IDL43-10
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    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.
    
  • Reported: IDL 4.2b1 — Sun, 4 Feb 2018 13:56 GMT
  • Updated: Thu, 1 Mar 2018 00:28 GMT

Apparently incomplete phrase

  • Key: IDL43-7
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    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".

  • Reported: IDL 4.2b1 — Wed, 31 Jan 2018 01:04 GMT
  • Updated: Thu, 1 Mar 2018 00:28 GMT

Typo in title of 7.4.1.4.1

  • Key: IDL43-3
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

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

    7.4.1.4.1 IDL Specification>

  • Reported: IDL 4.2b1 — Tue, 30 Jan 2018 02:22 GMT
  • Updated: Thu, 1 Mar 2018 00:28 GMT

Typo in Annex A: Consolidated IDL Grammar

  • Key: IDL43-5
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    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.

  • Reported: IDL 4.2b1 — Mon, 29 Jan 2018 18:59 GMT
  • Updated: Thu, 1 Mar 2018 00:28 GMT

Copy/paste problem at

  • Key: IDL43-8
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    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 <
    
  • Reported: IDL 4.2b1 — Wed, 31 Jan 2018 06:52 GMT
  • Updated: Thu, 1 Mar 2018 00:28 GMT

Formatting error in title of 7.4.13.4

  • Key: IDL43-2
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    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.

  • Reported: IDL 4.2 — Fri, 8 Dec 2017 23:10 GMT
  • Updated: Thu, 1 Mar 2018 00:28 GMT

Typo in section 7.4.1.4.4.4.3 Enumerations

  • Key: IDL43-1
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    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 32

  • Reported: IDL 4.2 — Fri, 8 Dec 2017 22:41 GMT
  • Updated: Thu, 1 Mar 2018 00:28 GMT

Constants for Core Data Types

  • Key: IDL43-21
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

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

    • sequence
    • structure
    • union
    • array
  • Reported: IDL 4.2b1 — Mon, 26 Feb 2018 22:10 GMT
  • Updated: Wed, 28 Feb 2018 17:36 GMT

Missing bullet "Integers restricted to holding 8 bits of information"

  • Key: IDL43-9
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    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.

  • Reported: IDL 4.2b1 — Sun, 4 Feb 2018 13:38 GMT
  • Updated: Sun, 11 Feb 2018 05:57 GMT

Syntax of annotation_appl requires clarification

  • Key: IDL43-4
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    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.

  • Reported: IDL 4.2b1 — Fri, 26 Jan 2018 22:03 GMT
  • Updated: Tue, 30 Jan 2018 19:42 GMT