Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — All Issues

  • Acronym: CORBA
  • Issues Count: 4
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

Unclear and possibly harmful consequences of mandatory annotation definitions

  • Legacy Issue Number: 19738
  • Status: open  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    The current mandatory annotation definitions (7.4.15.4.1) will cause problems when IDL specifications are attempted to be reused between profiles applying different requirements concerning annotations (for example a profile with annotations and a profile without annotations or two or more profiles with different sets of annotations).

    As the IDL 4 specification has removed the support for the commented form of annotations there is no possibility anymore to declare annotations in a form that has semantic meaning in one profile and does not cause parsing errors in another profile not supporting (these) annotations.
    Even with the commented form supported the mandatory specification of annotation definitions for applied annotations would cause similar kind of problems as it is likely that the definitions for the standard set of annotations from one profile would not be available in another profile not supporting those annotations.

    Personally I do not see any use for annotation definitions (and in fact I cannot find any commentaries regarding that in the spec) but I would suggest that at the very least IDL compilers should be allowed to ignore any annotations not known to the profile for which the IDL compiler is configured.
    Ideally I would like to see a specification without any mandatory annotation definitions leaving it up to the tool supplier to enforce annotation definitions or implement implicit (embedded) definitions.

  • Reported: CORBA 3.1.1 — Tue, 31 Mar 2015 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:38 GMT

Unclear and possibly harmful consequences of mandatory annotation definitions

  • Legacy Issue Number: 19738
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    The current mandatory annotation definitions (7.4.15.4.1) will cause problems when IDL specifications are attempted to be reused between profiles applying different requirements concerning annotations (for example a profile with annotations and a profile without annotations or two or more profiles with different sets of annotations).

    As the IDL 4 specification has removed the support for the commented form of annotations there is no possibility anymore to declare annotations in a form that has semantic meaning in one profile and does not cause parsing errors in another profile not supporting (these) annotations.
    Even with the commented form supported the mandatory specification of annotation definitions for applied annotations would cause similar kind of problems as it is likely that the definitions for the standard set of annotations from one profile would not be available in another profile not supporting those annotations.

    Personally I do not see any use for annotation definitions (and in fact I cannot find any commentaries regarding that in the spec) but I would suggest that at the very least IDL compilers should be allowed to ignore any annotations not known to the profile for which the IDL compiler is configured.
    Ideally I would like to see a specification without any mandatory annotation definitions leaving it up to the tool supplier to enforce annotation definitions or implement implicit (embedded) definitions.

  • Reported: CORBA 3.1.1 — Tue, 31 Mar 2015 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Typo in set_values

  • Key: CORBA32-1
  • Legacy Issue Number: 16994
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The set_values is defined as

    void set_values(
    in NVLis values // property values to set
    );

    but should be

    void set_values(
    in NVList values // property values to set
    );

  • Reported: CORBA 3.1.1 — Thu, 12 Jan 2012 05:00 GMT
  • Disposition: Resolved — CORBA 3.2
  • Disposition Summary:

    In CORBA v3.3 Part 1 Interfaces, section8.6.2.2 change
    in NVLis
    to
    in NVList

  • Updated: Fri, 6 Mar 2015 23:16 GMT

context:delete_values has type

  • Key: CORBA32-2
  • Legacy Issue Number: 16995
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    delete_values is define as

    void delete_values(
    in Identifie prop_name // name of property(s) to delete
    );

    but should be

    void delete_values(
    in Identifier prop_name // name of property(s) to delete
    );

  • Reported: CORBA 3.1.1 — Thu, 12 Jan 2012 05:00 GMT
  • Disposition: Resolved — CORBA 3.2
  • Disposition Summary:

    In CORBA v3.3 Part 1 Interfaces, section section 8.6.2.4 replace:
    in Identifie
    with
    in Identifier

  • Updated: Fri, 6 Mar 2015 23:16 GMT