Interface Definition Language Avatar
  1. OMG Specification

Interface Definition Language — Open Issues

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

Issues Descriptions

Syntax and scoping when applying annotations requires clarification

  • Key: IDL43-4
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. 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

Constants for Core Data Types

  • Key: IDL43-21
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. 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:

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

  • Key: IDL43-9
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. 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

Typos in 8.2.2 enumerated list

  • Key: IDL43-22
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. 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

Unicode apostrophe in source code

  • Key: IDL43-11
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. 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 ( Mr. Oliver M. 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 ( Mr. Oliver M. 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 ( Mr. Oliver M. 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 ( Mr. Oliver M. 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 ( Mr. Oliver M. 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 ( Mr. Oliver M. 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