Interface Definition Language Avatar
  1. OMG Specification

Interface Definition Language — Open Issues

  • Acronym: IDL
  • Issues Count: 74
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
IDL4JAV11-3 Sequences are not concretized IDL4-Java 1.0a1 open
IDL43-66 Add ruby as language IDL 4.2 open
IDL43-33 Need builtin annotations that can be used to document the IDL IDL 4.2 open
IDL43-4 Syntax and scoping when applying annotations requires clarification IDL 4.2b1 open
IDL43-32 Table formatting IDL 4.2 open
IDL43-21 Constants for Core Data Types IDL 4.2b1 open
IDL43-56 Clarify recursive/forwarded rules for maps IDL 4.2 open
IDL43-49 Add c++11 as language IDL 4.2 open
IDL43-54 Allow nested module definitions IDL 4.2 open
IDL4JAV11-20 Definition of CORBA specific Any (A.1.4 Any) needs to align with 7.3 Any IDL4-Java 1.0b2 open
IDL43-53 Clarify meaning of array and sequence annotations IDL 4.2 open
IDL43-27 Specify where annotations can be applied IDL 4.2 open
IDL4JAV11-1 @java_mapping promote_integer_width does not mention octet IDL4-Java 1.0 open
IDL43-50 optional should be a keyword, not an annotaton IDL 4.2 open
IDL4CSP11-7 The class shall implement the IEquatable interface, where T is the corresponding class name. IDL4-CSHARP 1.0 open
IDL4CSP11-8 Use of annotations as part of IDL example do not provide a clean example IDL4-CSHARP 1.0 open
IDL4CSP11-6 Use of anonymous array type in array section IDL4-CSHARP 1.0 open
IDL43-52 Remove the bifuration of basic and full inetrfaces IDL 4.2 open
IDL43-51 Behaviour when nested is not present should be standardized IDL 4.2 open
IDL4CSP11-5 Sections mapped to naming schemes complicates the document IDL4-CSHARP 1.1b1 open
IDL4CSP11-4 A canonical example for sequences is missing IDL4-CSHARP 1.0 open
IDL4CSP11-3 Basic types include extended types IDL4-CSHARP 1.1b1 open
IDL43-45 Missing hyperlinks for CORBA speficiations IDL 4.2 open
IDL43-48 any value of annotations underspecified IDL 4.2 open
IDL43-47 Mutable and changing annotations IDL 4.2 open
IDL43-46 extensibility underspecified IDL 4.2 open
IDL43-24 inheritance of unions and enumerations IDL 4.2 open
IDL4JAV11-19 Missing extended basic types section IDL4-Java 1.0 open
IDL4JAV11-18 Mapping to alternative identifier formats IDL4-Java 1.0 open
IDL4JAV11-17 Application of Non-Standard Annotations IDL4-Java 1.0 open
IDL4JAV11-16 Annotation usage IDL4-Java 1.0 open
IDL4JAV11-15 Anonymous types sections needs text IDL4-Java 1.0 open
IDL4JAV11-14 Annotations should not be used for examples in a canonical mapping IDL4-Java 1.0 open
IDL4JAV11-13 Union exmple uses octet which is not allowed as a discrimant IDL4-Java 1.0 open
IDL4JAV11-12 Table 7.2 IDL4-Java 1.0 open
IDL4JAV11-11 Document Review: Table 7.1 IDL4-Java 1.0 open
IDL43-44 Feature macros to guard building blocks IDL 4.2 open
IDL43-43 Ability to add annotations by reference IDL 4.2 open
IDL43-9 Missing bullet "Integers restricted to holding 8 bits of information" IDL 4.2b1 open
IDL43-42 Annotation for union discriminator name IDL 4.2 open
IDL43-41 Restrict bitshifts IDL 4.2 open
IDL43-40 Allow enumerator value to be set without using @value IDL 4.2 open
IDL4CSP11-2 Union implicit default IDL4-CSHARP 1.1b1 open
IDL43-39 Use of Omg.Types IDL4-CSHARP 1.1b1 open
IDL4CSP11-1 Partial classes cannot span assemblies IDL4-CSHARP 1.1b1 open
IDL43-38 Allow empty IDL modules IDL 4.2 open
IDL43-37 Explain how to handle when an annotation appears in attributes with multiple declarators IDL 4.2 open
IDL43-36 clarify forwarding rules related to structure inheritance IDL 4.2 open
IDL43-35 Importing a name scope recursively imports all name scopes nested within it IDL 4.2 open
IDL43-34 Need the concept of a "using namespace" directive to simplify IDL files 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-29 References to a Template Module: Syntax doesn't match example IDL 4.1 open
IDL43-28 Extended structs that are both inheriting and empty IDL 4.2 open
IDL43-26 Some standardized annotations use keywords as identifiers 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
IDL4JAV11-10 Bitset inheritance IDL4-Java 1.0b2 open
IDL4JAV11-8 Typo fixes IDL4-Java 1.0a1 open
IDL4JAV11-9 Typos and Inconsistencies IDL4-Java 1.0a1 open
IDL4JAV11-5 Provide strong abstraction for arrays IDL4-Java 1.0a1 open
IDL4JAV11-7 Anonymous types are a separate Building Block IDL4-Java 1.0a1 open
IDL4JAV11-6 Union mapping IDL4-Java 1.0a1 open
IDL4JAV11-4 Interfaces - Full should define a FooOperations interface IDL4-Java 1.0a1 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-12 Incorrect rule number on 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-7 Apparently incomplete phrase 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

Issues Descriptions

Sequences are not concretized

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    ptc/19-07-02 section 7.2.4.2.1 defines the mapping of sequences of basic and non basic types in terms of Java interfaces.
    However, the classes implementing the interfaces are not defined.
    The implementation classes are required for actual programming.
    If it is intended that the user shall provide own implementations then this should be expressly stated.

  • Reported: IDL4-Java 1.0a1 — Mon, 23 Mar 2020 04:47 GMT
  • Updated: Tue, 20 Sep 2022 21:07 GMT

Add ruby as language

  • Key: IDL43-66
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    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

  • Reported: IDL 4.2 — Tue, 7 Jun 2022 06:34 GMT
  • Updated: Thu, 14 Jul 2022 15:38 GMT

Need builtin annotations that can be used to document the IDL

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

    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
     };
    
  • Reported: IDL 4.2 — Thu, 11 Apr 2019 18:17 GMT
  • Updated: Tue, 21 Jun 2022 23:19 GMT

Syntax and scoping when applying annotations 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, 21 Jun 2022 23:16 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: Tue, 21 Jun 2022 20:54 GMT

Constants for Core Data Types

  • Key: IDL43-21
  • Status: open  
  • Source: Object Computing, Inc. - 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: Tue, 21 Jun 2022 20:13 GMT
  • Attachments:

Clarify recursive/forwarded rules for maps

  • Key: IDL43-56
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    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.

  • Reported: IDL 4.2 — Fri, 3 Jun 2022 19:49 GMT
  • Updated: Fri, 3 Jun 2022 19:49 GMT

Add c++11 as language

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

    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

  • Reported: IDL 4.2 — Thu, 19 Aug 2021 08:41 GMT
  • Updated: Fri, 3 Jun 2022 19:44 GMT

Allow nested module definitions

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

    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

    { struct Foo; // Forward declaration typedef sequence<Foo> FooSeq; }
    }
    }

    It would be much easier that we can do the following (based on the C++17 namespace changes also allowing that for namespaces)

    module A::B::C { struct Foo; // Forward declaration typedef sequence<Foo> FooSeq; }
  • Reported: IDL 4.2 — Thu, 28 Oct 2021 11:10 GMT
  • Updated: Wed, 3 Nov 2021 17:53 GMT

Definition of CORBA specific Any (A.1.4 Any) needs to align with 7.3 Any

  • Status: open  
  • Source: Micro Focus ( Simon McQueen)
  • Summary:

    7.3 Any says:

    "The IDL any type shall be mapped to org.omg.type.Any type."

    A.1.4 Any says:

    "The IDL type any maps to a public class named org.omg.CORBA.Any with the following definition

    package org.omg.CORBA;
    public class Any {
    ..."

    Suggested solution:

    Replace class declaration with:

    "package org.omg.CORBA;
    public class Any implements org.omg.type.Any {
    ..."

  • Reported: IDL4-Java 1.0b2 — Thu, 14 Oct 2021 11:04 GMT
  • Updated: Thu, 14 Oct 2021 12:27 GMT

Clarify meaning of array and sequence annotations

  • Key: IDL43-53
  • Status: open  
  • Source: MIT/Lincoln Laboratory ( Daniel Herring)
  • Summary:

    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?

  • Reported: IDL 4.2 — Wed, 29 Sep 2021 16:31 GMT
  • Updated: Wed, 29 Sep 2021 16:32 GMT

Specify where annotations can be applied

  • Key: IDL43-27
  • Status: open  
  • Source: Object Computing, Inc. - 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: Wed, 29 Sep 2021 16:32 GMT

@java_mapping promote_integer_width does not mention octet

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    IDL 4.2 section 7.4.1.4.3 Constants consistency rules on page 32 contains

    • An octet constant can be defined using an integer literal or an integer constant expression but values outside the range 0…255 shall be treated as an error.

    ptc/20-05-17 section 7.2.4.1.6 maps IDL octet to Java byte.
    For mapping IDL const octet values 128 to 255 to Java, it should be permissible to apply promote_integer_width to octet.

  • Reported: IDL4-Java 1.0 — Fri, 10 Jul 2020 08:28 GMT
  • Updated: Tue, 28 Sep 2021 17:42 GMT

optional should be a keyword, not an annotaton

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

    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.

  • Reported: IDL 4.2 — Fri, 20 Aug 2021 08:03 GMT
  • Updated: Wed, 8 Sep 2021 16:37 GMT

The class shall implement the IEquatable interface, where T is the corresponding class name.

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    This should be changed to a "may" or a "could". Shall seems overly prescriptive.

    How could a compliant implementation of Equals<T> be distinguished from Equals(Object) from the callers/users perspective?

  • Reported: IDL4-CSHARP 1.0 — Mon, 30 Aug 2021 21:22 GMT
  • Updated: Wed, 8 Sep 2021 15:00 GMT

Use of annotations as part of IDL example do not provide a clean example

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    The annotations should be covered in a separate section of the document and NOT be part of a clean, canonical example.

    Suggest:
    // IDL
    enum E

    {x, y, z}

    ;

    // C#
    public enum E

    { x, y, z }

    ;

    Also should enums inherit uint?

  • Reported: IDL4-CSHARP 1.0 — Mon, 30 Aug 2021 21:28 GMT
  • Updated: Wed, 8 Sep 2021 15:00 GMT

Use of anonymous array type in array section

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    Anonymous types should be moved to their own section

    Suggest:

    //IDL
    typedef long myLongArray[2][3];

    // C# example

  • Reported: IDL4-CSHARP 1.0 — Mon, 30 Aug 2021 21:32 GMT
  • Updated: Wed, 8 Sep 2021 15:00 GMT

Remove the bifuration of basic and full inetrfaces

  • Key: IDL43-52
  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    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.

  • Reported: IDL 4.2 — Wed, 8 Sep 2021 14:55 GMT
  • Updated: Wed, 8 Sep 2021 14:55 GMT

Behaviour when nested is not present should be standardized

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

    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.

  • Reported: IDL 4.2 — Mon, 23 Aug 2021 17:18 GMT
  • Updated: Wed, 8 Sep 2021 14:33 GMT

Sections mapped to naming schemes complicates the document

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    Suggestion is to have one section or appendix where possible naming mappings could be covered.

    Change the IDL example naming to match the C# community expectations if that makes it easier to specify

  • Reported: IDL4-CSHARP 1.1b1 — Mon, 30 Aug 2021 21:18 GMT
  • Updated: Wed, 8 Sep 2021 14:22 GMT

A canonical example for sequences is missing

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    Beside basic types no other canonical example is included. I suggest removing the basic types and having one example.

    // IDL
    struct foo

    {...};
    typedef sequence<foo> fooSeq;

    // C#
    class fooSeq : IDL:ISequences<foo> {...}

    ;

    Something like this.

  • Reported: IDL4-CSHARP 1.0 — Mon, 30 Aug 2021 21:13 GMT
  • Updated: Wed, 8 Sep 2021 14:22 GMT

Basic types include extended types

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    Types such as sbyte and int32 are included in this section and should not be.

    These types should be moved to the extended types section.

    The section for these types is missing from the document.

  • Reported: IDL4-CSHARP 1.1b1 — Mon, 30 Aug 2021 21:09 GMT
  • Updated: Wed, 8 Sep 2021 14:21 GMT

Missing hyperlinks for CORBA speficiations

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

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

  • Reported: IDL 4.2 — Thu, 19 Aug 2021 07:40 GMT
  • Updated: Thu, 19 Aug 2021 14:25 GMT

any value of annotations underspecified

  • Key: IDL43-48
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: IDL 4.2 — Thu, 19 Aug 2021 08:18 GMT
  • Updated: Thu, 19 Aug 2021 14:22 GMT

Mutable and changing annotations

  • Key: IDL43-47
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: IDL 4.2 — Thu, 19 Aug 2021 08:05 GMT
  • Updated: Thu, 19 Aug 2021 14:22 GMT

extensibility underspecified

  • Key: IDL43-46
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: IDL 4.2 — Thu, 19 Aug 2021 07:54 GMT
  • Updated: Thu, 19 Aug 2021 14:21 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: Thu, 19 Aug 2021 08:09 GMT

Missing extended basic types section

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    This building block section is missing (e.g. sbyte).

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:24 GMT
  • Updated: Wed, 11 Aug 2021 17:24 GMT

Mapping to alternative identifier formats

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    It seems every section has this deviation of alternative identifier mappings. I find that it maps the document more difficult to read. The document at large should provide canonical text and examples. These alternatives should be placed in a section that caters to those alternatives with easy links to this section elsewhere in the document.

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:23 GMT
  • Updated: Wed, 11 Aug 2021 17:23 GMT

Application of Non-Standard Annotations

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    I could not find a place that discussed what is expected if an IDL compiler encounters an annotation that it can parse but does not understand.

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:17 GMT
  • Updated: Wed, 11 Aug 2021 17:17 GMT

Annotation usage

  • Status: open   Implementation work Blocked
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    The section on annotations should contain examples of how to use the various standard annotations.

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:14 GMT
  • Updated: Wed, 11 Aug 2021 17:14 GMT

Anonymous types sections needs text

  • Status: open   Implementation work Blocked
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    This section needs to be filled out with examples of anonymous IDL types.

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:12 GMT
  • Updated: Wed, 11 Aug 2021 17:12 GMT

Annotations should not be used for examples in a canonical mapping

  • Status: open   Implementation work Blocked
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    The example uses annotation to define the type. The mapping should be clean/pure without annotations. The annotation should be moved to the sections on annotations.
    // IDL
    enum AnEnum

    { X, Y }

    ;

    // Java
    public enum AnEnum {
    X,
    Y;
    private int value;
    private AnEnum(int value)

    { this.value = value; }

    public int getValue()

    { return value; }

    public static AnEnum valueOf(int v)

    { // return X, Y, or raise java.lang.RuntimeException }

    7.17 Standardized Annotations
    }

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:09 GMT
  • Updated: Wed, 11 Aug 2021 17:09 GMT

Union exmple uses octet which is not allowed as a discrimant

  • Status: open   Implementation work Blocked
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    Same as the description

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:07 GMT
  • Updated: Wed, 11 Aug 2021 17:07 GMT

Table 7.2

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    Ensure the correct separation of building block basic types (e.g. sbye)

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:04 GMT
  • Updated: Wed, 11 Aug 2021 17:04 GMT

Document Review: Table 7.1

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    There needs to be a section on IDL interfaces being mapped to Java 8 interfaces which provide the capability to be a proper container. This removes the need for the old fooPackage id foo were defined in an IDL interface named foo.

  • Reported: IDL4-Java 1.0 — Wed, 11 Aug 2021 17:02 GMT
  • Updated: Wed, 11 Aug 2021 17:02 GMT

Feature macros to guard building blocks

  • Key: IDL43-44
  • Status: open  
  • Source: MIT/Lincoln Laboratory ( Daniel Herring)
  • Summary:

    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.

  • Reported: IDL 4.2 — Tue, 15 Jun 2021 21:14 GMT
  • Updated: Wed, 16 Jun 2021 07:26 GMT

Ability to add annotations by reference

  • Key: IDL43-43
  • Status: open  
  • Source: MIT/Lincoln Laboratory ( Daniel Herring)
  • Summary:

    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.

  • Reported: IDL 4.2 — Tue, 15 Jun 2021 20:56 GMT
  • Updated: Tue, 15 Jun 2021 20:56 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: Tue, 15 Jun 2021 19:41 GMT

Annotation for union discriminator name

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

    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.

  • Reported: IDL 4.2 — Sat, 1 May 2021 16:43 GMT
  • Updated: Sun, 23 May 2021 10:32 GMT

Restrict bitshifts

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

    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

  • Reported: IDL 4.2 — Mon, 10 May 2021 10:21 GMT
  • Updated: Tue, 11 May 2021 13:54 GMT

Allow enumerator value to be set without using @value

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

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

    enum Test_E

    { @value(8) TEST_NO, @value(10) TEST_YES }

    ;

    It would be more clear and logical when IDL would allow

    enum Test_E

    { TEST_NO = 8, TEST_YES = 10 }

    ;

  • Reported: IDL 4.2 — Tue, 13 Apr 2021 06:21 GMT
  • Updated: Tue, 13 Apr 2021 12:56 GMT

Union implicit default

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    The section that describes the default value does not include a discussion
    of what to do when a default is not present. In this case a method called _default or
    __default should be defined to set the discriminant to a non-switched field value.
    This should be fixed before December.

  • Reported: IDL4-CSHARP 1.1b1 — Wed, 24 Mar 2021 13:57 GMT
  • Updated: Thu, 1 Apr 2021 15:55 GMT

Use of Omg.Types

  • Key: IDL43-39
  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

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

  • Reported: IDL4-CSHARP 1.1b1 — Fri, 26 Mar 2021 15:40 GMT
  • Updated: Fri, 26 Mar 2021 15:40 GMT

Partial classes cannot span assemblies

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    Every scope containing a constant declaration shall contain a public static partial class.

    The "public static partial class" is inconsistent with the examples in 7.2.3.1 above.

    The use of "partial" is suspect and cannot span assemblies. It may be useful for forward interface declarations though whose definition appears in another IDL file.

  • Reported: IDL4-CSHARP 1.1b1 — Wed, 24 Mar 2021 13:22 GMT
  • Updated: Wed, 24 Mar 2021 13:47 GMT

Allow empty IDL modules

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

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

    {" <definition>* "}

    " 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

  • Reported: IDL 4.2 — Fri, 26 Feb 2021 09:39 GMT
  • Updated: Tue, 23 Mar 2021 20:56 GMT

Explain how to handle when an annotation appears in attributes with multiple declarators

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

    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.

  • Reported: IDL 4.2 — Tue, 8 Dec 2020 16:09 GMT
  • Updated: Tue, 23 Mar 2021 20:54 GMT

clarify forwarding rules related to structure inheritance

  • Key: IDL43-36
  • Status: open  
  • Source: Real-Time Innovations ( Dave Stringer)
  • Summary:

    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.

  • Reported: IDL 4.2 — Wed, 7 Oct 2020 13:56 GMT
  • Updated: Tue, 23 Mar 2021 20:51 GMT

Importing a name scope recursively imports all name scopes nested within it

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

    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.

  • Reported: IDL 4.2 — Mon, 29 Jun 2020 07:47 GMT
  • Updated: Tue, 23 Mar 2021 20:50 GMT

Need the concept of a "using namespace" directive to simplify IDL files

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

    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

  • Reported: IDL 4.2 — Tue, 23 Jun 2020 03:14 GMT
  • Updated: Tue, 23 Mar 2021 20:46 GMT

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

  • Key: IDL43-31
  • Status: open  
  • Source: Object Computing, Inc. - 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: Tue, 23 Mar 2021 20:31 GMT

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

  • Key: IDL43-30
  • Status: open  
  • Source: ZettaScale Technology ( 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, 23 Mar 2021 20:31 GMT

References to a Template Module: Syntax doesn't match example

  • Key: IDL43-29
  • Status: open   Implementation work Blocked
  • Source: Honeywell ( Steven Hickman)
  • Summary:

    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;

  • Reported: IDL 4.1 — Tue, 22 Jan 2019 18:48 GMT
  • Updated: Tue, 23 Mar 2021 20:29 GMT

Extended structs that are both inheriting and empty

  • Key: IDL43-28
  • Status: open  
  • Source: Object Computing, Inc. - 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: Tue, 23 Mar 2021 20:28 GMT

Some standardized annotations use keywords as identifiers

  • Key: IDL43-26
  • Status: open  
  • Source: Object Computing, Inc. - 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: Tue, 23 Mar 2021 20:24 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, 23 Mar 2021 20:21 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, 23 Mar 2021 20:07 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: Tue, 23 Mar 2021 20:07 GMT

Bitset inheritance

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    How are bitsets that use inheritance mapped?

  • Reported: IDL4-Java 1.0b2 — Tue, 20 Oct 2020 18:02 GMT
  • Updated: Tue, 20 Oct 2020 18:05 GMT

Typo fixes

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    In section 7.2.4.2.1.1 on page 13 top of page after end of fixed font Java code:

    Where:
    • <IntarfaceName> is the interface name indicated in Table 7.4.

    <IntarfaceName> should be <InterfaceName>

    In Clause 7.2.4.2.1.2, Sequence of non Basic Types, the text describing when to throw an exception is somewhat repetitive.

    In Clause 7.2.4.3.2 Unions, the requirement for implementing java.io.Serializable is repeated.

    In section 7.2.4.3.2 on page 16 paragraph before the union U1 example:

    [...] The first modifier method shall
    take no arguments, return void, and setsthe discriminant to the first available default value starting from a 0 index of the
    discriminant type.

    setsthe should be set the.

    In section 8.1.3 table 8.2 column "IDL Construct", repeated typo:
    Accesor should be Accessor.
    In particular, on page 32:

    Structure Member Name in
    Accesor/Modifier Methods

    Union Member Name in
    Accesor/Modifier Methods

    and on page 33:

    Interface Attribute Name in
    Accesor/Modifier Methods

    Exception Member Name in
    Accesor/Modifier Methods

    Bitfield Name in Bitset
    Accesor/Modifier Methods

    Throughout the document URIs starting with "http://" should start with "https://" instead.

  • Reported: IDL4-Java 1.0a1 — Mon, 30 Dec 2019 12:49 GMT
  • Updated: Tue, 14 Jul 2020 20:04 GMT

Typos and Inconsistencies

  • Status: open  
  • Source: Real-Time Innovations ( Fernando Garcia-Aranda)
  • Summary:

    The revised submission contains a number of typos and inconsistencies that should be fixed:

    • In Clause 7.2.4.2.1.1, Sequence of Basic Types, IntarfaceName should be InterfaceName.
    • In Clause 7.2.4.2.1.2, Sequence of non Basic Types, the text describing when to throw an exception is somewhat repetitive.
    • In Clause 7.2.4.3.2 Unions, the requirement for implementing java.io.Serializable is repeated.
  • Reported: IDL4-Java 1.0a1 — Sat, 21 Mar 2020 13:43 GMT
  • Updated: Tue, 14 Jul 2020 20:04 GMT

Provide strong abstraction for arrays

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    The ptc/19-07-02 section 7.2.4.4 proposes a weak mapping for IDL arrays in that they are mapped directly to Java arrays.
    This means that the fixed size nature of IDL arrays cannot be enforced at the location of usage (e.g. index checking and handling of variable size operations of java.util.List).

    On the other hand, 7.2.4.2.1.1 does define an abstraction for "Sequence of Basic Types", see Table 7.4 where e.g. sequence<boolean> is mapped to the interface BooleanSeq.
    A similar mapping could be defined for IDL arrays.

    Example:

      // IDL
      enum Color { RED, GREEN, BLUE };
    
      typedef Color ColorArray[3];
    

    could be mapped to

      public enum Color {
        // [...]
      }
    
      public class ColorArray implements org.omg.type.Array<Color> {
        public ColorArray() {
          elementData = new Color[3];   // initialize private member
        }
        // [...] most of the operations can be implemented in the superclass
      }
    

    The generic abstract class org.omg.type.Array would provide getter, setter, and other methods. It could also throw an exception on use of java.util.List operations that undermine the fixed size. I can provide a demo implementation of the class if desired.

    If it is desired to maintain the possibility of using plain Java arrays then the mapping could be made switchable via an annotation.

  • Reported: IDL4-Java 1.0a1 — Mon, 23 Mar 2020 05:24 GMT
  • Updated: Tue, 14 Jul 2020 20:04 GMT
  • Attachments:

Anonymous types are a separate Building Block

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    Examples given throughout ptc/19-07-02 make indiscriminate use of anonymous types; see

    • 7.2.4.2.1.2 struct MyType
    • 7.2.4.4 struct S2
    • 7.2.4.6 struct MyType
    • 7.14.3.1 struct S4

    For IDL compatibility with other mappings that do not support anonymous types (see e.g. C++11 mapping version 1.4 stion 6.2), the examples should preferably use typedefs.
    Further, it should be mentioned that anonymous types can incur portability problems when used with other language mappings.

  • Reported: IDL4-Java 1.0a1 — Mon, 23 Mar 2020 05:01 GMT
  • Updated: Tue, 14 Jul 2020 20:04 GMT

Union mapping

  • Status: open  
  • Source: Objective Interface Systems ( Chuck Abbott)
  • Summary:

    Something I noticed while looking at the union mapping for CORBA. Why is it that the IDL4 mapping uses two underscores prepended to the default method (e.g. __default v.s. _default)?

    If there is no technical reason for it I think the single underscore is preferred.

  • Reported: IDL4-Java 1.0a1 — Wed, 6 May 2020 21:07 GMT
  • Updated: Tue, 14 Jul 2020 20:04 GMT

Interfaces - Full should define a FooOperations interface

  • Status: open  
  • Source: Real-Time Innovations ( Fernando Garcia-Aranda)
  • Summary:

    Interfaces - Full should define a FooOperations interface like we have done in the IDL to C# Language Mapping.

    Also, public abstract void op1(S sIn); should be changed to void op1(S sIn);.

  • Reported: IDL4-Java 1.0a1 — Tue, 10 Dec 2019 21:57 GMT
  • Updated: Tue, 14 Jul 2020 20:04 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

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

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

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

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