Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
This issue gathers a number of typographical error and grammatical improvements that woudl enhance the readability of the specification.
In section 8.3.3 (Group of Annotations: Units and Ranges) in the declaration of struct Foo it uses the keyword "Struct". It should be "struct" instead.
Section 2 (Conformance Criteria) edit the first sentence of the first paragraph as shown below:
This document defines IDL
forother specifications to reference andcontains no independent conformance points.
Section 2 (Conformance Criteria) edit the 3rd sentence of the first paragraph as shown below:
However, the general organization of the clauses (by means of atomic building blocks and profiles that group them
as detailed afterwards) is intended to ease conformance description and scoping.
Section 2 (Conformance Criteria) edit the bullets as shown below:
Any future specification usingIDL shall reference this IDL standard .
2. Future revisions of current specifications
usingIDL may reference this IDL standard .
3. Reference to this standard
mustresult in a selection of building blocks possibly complemented by groups of annotations.
a. All selected building blocks
mustbe supported entirely.
b. Selected annotations
mustbe either supported as described in 8.2.2 Rules for Using Standardized Annotations, or fully ignored. In the latter case, the usingspecification shall not define a specific annotation, either with the same name and another meaning or with the same meaning and another name.
Section 7.1 (Overview) edit the 2rd paragraph as shown below:
OMG IDL is a language that allows
interfaces that client objects may use and object implementations provide as well as all needed related constructs such as exceptions
ordata types. Data types are needed to specify parameters and return value of interfaces' operations. They can be used also as first class constructs.
Section 7.1 (Overview) edit the 3rd paragraph as shown below:
IDL is a purely descriptive language. This means that
invoking operations, implementing them or creating and accessing datacannot be written in IDL, but in a programming language, for which mappings from IDL constructs have been defined. The mapping of an IDL constructto a programming language constructwill depend on the facilities available in theprogramming language. For example, an IDL exception might be mapped to a structure in a language that has no notion of exception, or to an exception in a language that does. The binding of IDL constructs to several programming languages is described in separate specifications.
In Section 7.1 (Overview) edit the 4th paragraph as shown below:
A source file containing specifications written in IDL
musthave a ".idl" extension.
In Section 7.1 (Overview) edit the 5th paragraph as shown below:
The description of IDL grammar uses a syntax notation that is similar to Extended Backus-Naur Format (EBNF). However, to allow composition of specific parts of the description, while avoiding redundancy; a
specificoperator (::+) has been added. This operator allows adding alternatives to an existing definition (assuming x ::= y, x ::+ z means actually x ::= y | z). z shall be interpreted as x ::= y | z.
In Section 220.127.116.11.1 (Wide and Non-wide Characters) modify the last sentence as shown below:
Attempts to assign a wide character literal to a non-wide character constant, or to assign a non-wide character literal to a wide character constant,
result in a compile-time diagnostic.
In Section 18.104.22.168.2 (Escape Sequences to Represent Character Literals) change the two occurrences of "must" to "shall" as shown below:
mustbe represented using escape sequences as defined below in Table 7 9. Note that escape sequences mustbe used to represent single quote and backslash characters in character literals.
In Section 22.214.171.124 (Purpose) edit the first paragraph as shown below:
This building block constitutes the core of any IDL specialization (all other building blocks assume that this one is included). It
gathers allthat allow defining most data types with what allowsIDL basic structuring (i.e., modules). and, becauseit is the only building block which is mandatory,the root nonterminal <specification> for the grammar itself.
In Section 126.96.36.199.3 (Constants) first paragraph, change "must" to "shall" as shown below.
mustfollow the following rules:
In Section 188.8.131.52.3 (Constants)
Perform edits changing:
"which must" to "which shall",
"rules are applied" to "rules shall be applied",
"are applicable" to "shall be applicable",
"are evaluated" to "shall be evaluated",
"are considered" to "shall be considered",
"are not considered" to "shall not be considered",
"is considered" to "shall be considered",
"are discarded" to "shall be discarded",
"are multiplied" to "shall be multiplied",
"is divided" to "shall be divided",
"are added" to "shall be added",
"is subtracted" to "shall be subtracted",
"is not performed" to "shall not be performed"
"can combine" to "may combine",
"using the imputed type" to "based on"
"If either argument is ... use" to "If either argument is ... it shall use"
"an error shall be flagged by the compiler" "it shall be treated as an error"
"shall be flagged as a compile time error" to "shall be treated as an error"
"shall cause a compile-time error" to "shall be treated as an error"
"has no effect" to "shall have no effect"
"should be shifted" to "shall be shifted"
"should be generated" to "shall be generated"
In section 184.108.40.206.4 (Data Types) Change "can" to "may" in the first sentence as shown below:
A data type
canbe either a simple type or a constructed one. Those different kinds are detailed in the following clauses.
In section 220.127.116.11.4.1 (Simple Types) replace the first bullet:
• Basic types that basically represent numbers and characters and fully pre-exist any IDL specification.
• Basic types representing primitive builtin types such as numbers and characters.
In the same section replace: "Those two categories" with "These two categories"
In the same section edit 3rd paragraph as shown below
Note – Within this building block,
actual the typeresulting from an instantiation of a template type cannot be used as is (anonymously). Instead, it needs tobe given a name through a typedef declaration prior to any use. Therefore, as expressed in the following rules, referring to a simple type can be done either using directly its name, if it is a basic type, or througha scoped name, in all other cases:
In section 18.104.22.168.4.1.1 (Basic Types) Edit the first paragraph as shown below:
Basic types are pre-existing types that represent numbers or characters.
They aredefined by the following rules:
In section 22.214.171.124.4.2.4 (Constructed Recursive Types and Forward Declarations) change the 3 occurences of the sentence
Compilers shall issue a diagnostic if this rule is violated.
If this rule is violated it shall be treated as an error
In section 126.96.36.199.4.4 (Native Types) modify the second paragraph as shown below:
As stated in the following rules, declaring a native type
consist in justprefixing the type name (<simple_declarator>) with the native keyword:
In section 188.8.131.52 (Explanations and Semantics) edit the second paragraph as shown below:
An any logically contains a value and some means
that specifiesthe actual type of the value. This meansis middleware-specific . Each IDL language mapping provides operations that allow programmers to insert and access the value contained in an any as well as the actual type of that value.
In section 184.108.40.206.2 (Exceptions) change "is" with "shall be" as shown below:
If an exception is returned as the outcome to an operation invocation, then the value of the exception identifier
isaccessible to the programmer for determining which particular exception was raised.
In the same section, 3rd paragraph, change "will" with "shall be" ab "is" with "shall be" as shown below:
If an exception is declared with members, a programmer
willbe able to access the values of those members when such an exception is raised. If no members are specified, no additional information isaccessible when such an exception is raised.
In the same section, last paragraph, remove the word "thereafter"
In section 220.127.116.11.3 (Interfaces) modify the last sentence of the 2nd paragraph as shown:
An interface may also be declared with no definition
witha forward declaration (<interface_forward_dcl>).
In section 18.104.22.168.3.1 (Interface Header) modify the last paragraph as shown below:
A parameter or structure member which is of an interface type is
actuallysemantically asa reference to an object implementing that interface. Each language binding describes how the programmer must represent such interface references.
In section 22.214.171.124.3.3 (Interface Body) modify the first paragraph as shown below:
As stated in the following rules, within an interface body,
can be definedoperations and attributes . Those constructs are defined in the scope of the interface and exported (i.e., accessible outside the interface definition throughtheir name scoped by the interface name).
In section 126.96.36.199.3.3.1 (Operations) replace "must" with "shall" in:
Operations that do not return a result
mustspecify void as return type.
In the same section edit the paragraph below as shown:
The absence of a raises expression on an operation implies that there are no operation-specific exceptions. Invocations of such an operation
arestill liable to receiveone of the middleware-specific standard exceptions.
In section 188.8.131.52.3.3.2 (Attributes) replace "can" with "may" in the first sentence as shown:
canalso be declared within an interface.
In the same section edit the bullet below as shown:
• For plain attributes, raises expressions
allow toindicate which the potential user-defined exceptions arewhen the attribute is read (getraises) and which the ones arewhen the attribute is written (setraises). A plain attribute may have a getraises expression, a setraises expression or both of them. In the latter case, the getraises expression must be declared in first place.
In the same section edit the paragraph below as shown:
The absence of a raises expression (raises, getraises or setraises) on an attribute implies that there are no attribute-specific exceptions. Accesses to such an attribute
arestill liable to receivemiddleware-specific standard exceptions.
In section 184.108.40.206 (Explanations and Semantics) modify the 1st paragraph as shown below:
This building block adds the possibility to embed
inside an interface declaration,declarations of types, constants and exceptions .
In the same section modify the paragraph as shown below:
All those elements are exported (i.e., visible under the scope of their
hostinginterface). As opposedto attributes and operations, they may be redefined in a derived interface, which has the following consequences:
In the same section modify the last sentence in the paragraph as shown below:
An attempt to use an ambiguous name without qualification
produces a compilationerror.
In section 220.127.116.11 (Purpose) modify the 2nd paragraph as shown below:
As opposedto interfaces which are merely groups of operations , values carry also state contents. A value type is, in some sense, half way between a "regular" IDL interface type and a structure.
In the same section modify the second bullet as shown below:
Supports a singleinterface .
In section 18.104.22.168.1.3.1 (State Members) modify the last sentence in the first paragraph as shown below:
While its public part is exposed to all, the private part of the state is only accessible to the implementation code
and the marshaling routines.
In section 22.214.171.124.2 (Forward Declarations) modify the first sentence in the first paragraph as shown below:
Likeinterfaces, value types may be forward-declared, with the following syntax:
In section 126.96.36.199 (Explanations and Semantics) change "must" to "shall" in teh first bullet as shown below:
• A home declaration
mustspecify exactly one component type that it manages. Multiple homes may manage the same component type.
In section 188.8.131.52 (Purpose) modify the first paragraph as shown:
The purpose of this building block is to allow embedding constructs in template modules. Template modules may be parameterized by a variety of parameters (called formal parameters), which
by transitionmakes all the embedded constructs parameterized by the same parameters. Before using it, a template module needs to be instantiated with values suited for the formal parameters. A template module instantiation results in a de facto instantiation of all itsembedded constructs.
In section 184.108.40.206.1 (Defining Annotations) edit the last two notes as shown below:
Note – Annotations may be user-defined, using this syntax. They can also be implicitly defined by
a compiler. In the latter case, the behavior should be as if the related definitions were included at the beginning of the IDL specification.
Note – Annotations should not cause more
compileerrors than strictly needed. Therefore, in case of multiple definitions of the same annotation in one IDL specification , the compiler should accept them, provided that they are consistent. In return, compilers should raise an error in case of malformed definitions.
In section 220.127.116.11.2 (Applying Annotations) modify the first bullet as shown below:
• The annotation name (<scoped_name>) prefixed with the at symbol
In the same section modify the second note as shown below:
Note – Annotations should not cause more
compileerrors than strictly needed. Therefore, in case an unknown annotation is encountered, it should be simplyignored by the IDL-processing tools compiler. In return, compilers should raise an error in case of malformed annotations.
In section 7.5.1 (Qualified Names) modify the last paragraph as shown below:
The declaration of attribute Title in interface C is ambiguous, since the
compilerIDL-processor does not know which string_t is desired. Ambiguous declarations yield compilationerrors.
In section 8.2.2 (Rules for Using Standardized Annotations) modify the bullets as shown below:
Mustrespect totally the standardized annotation syntax.
• May clarify the actual meaning of the annotation in the specific targeted context. That actual meaning may be more precise than, but
mustremain compliant with, the general one expressed here.
Mustindicate the default behavior when no annotation is placed on an element that may be annotated. Note that this default is never identical tothe default values providedfor annotation members (when these default values exist). asthe later values are justintended to be the most logical when the annotation is present.
Reported: IDL 4.1 — Sun, 13 Aug 2017 23:16 GMT
Disposition: Resolved — IDL 4.2
Fix the typos and make the improvements suggested in the issue description.
Apply the changes suggested in the issue description.
Updated: Tue, 19 Dec 2017 20:04 GMT