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
for other specifications to reference and contains 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 using IDL shall reference this IDL standard .
2. Future revisions of current specifications
using IDL may reference this IDL standard .
3. Reference to this standard
must result in a selection of building blocks possibly complemented by groups of annotations.
a. All selected building blocks
must be supported entirely.
b. Selected annotations
must be either supported as described in 8.2.2 Rules for Using Standardized Annotations, or fully ignored. In the latter case, the using specification 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
or data 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 data cannot be written in IDL, but in a programming language, for which mappings from IDL constructs have been defined. The mapping of an IDL construct to a programming language construct will depend on the facilities available in the programming 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
must have 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
specific operator (::+) 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 18.104.22.168.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 22.214.171.124.2 (Escape Sequences to Represent Character Literals) change the two occurrences of "must" to "shall" as shown below:
must be represented using escape sequences as defined below in Table 7 9. Note that escape sequences must be used to represent single quote and backslash characters in character literals.
In Section 126.96.36.199 (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 all that allow defining most data types with what allows IDL basic structuring (i.e., modules). and, because it is the only building block which is mandatory, the root nonterminal <specification> for the grammar itself.
In Section 188.8.131.52.3 (Constants) first paragraph, change "must" to "shall" as shown below.
must follow the following rules:
In Section 184.108.40.206.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 220.127.116.11.4 (Data Types) Change "can" to "may" in the first sentence as shown below:
A data type
can be either a simple type or a constructed one. Those different kinds are detailed in the following clauses.
In section 18.104.22.168.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 type resulting from an instantiation of a template type cannot be used as is (anonymously). Instead, it needs to be 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 through a scoped name, in all other cases:
In section 22.214.171.124.4.1.1 (Basic Types) Edit the first paragraph as shown below:
Basic types are pre-existing types that represent numbers or characters.
They are defined by the following rules:
In section 126.96.36.199.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 188.8.131.52.4.4 (Native Types) modify the second paragraph as shown below:
As stated in the following rules, declaring a native type
consist in just prefixing the type name (<simple_declarator>) with the native keyword:
In section 184.108.40.206 (Explanations and Semantics) edit the second paragraph as shown below:
An any logically contains a value and some means
that specifies the actual type of the value. This means is 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 220.127.116.11.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
is accessible 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
will be able to access the values of those members when such an exception is raised. If no members are specified, no additional information is accessible when such an exception is raised.
In the same section, last paragraph, remove the word "thereafter"
In section 18.104.22.168.3 (Interfaces) modify the last sentence of the 2nd paragraph as shown:
An interface may also be declared with no definition
with a forward declaration (<interface_forward_dcl>).
In section 22.214.171.124.3.1 (Interface Header) modify the last paragraph as shown below:
A parameter or structure member which is of an interface type is
actually semantically as a reference to an object implementing that interface. Each language binding describes how the programmer must represent such interface references.
In section 126.96.36.199.3.3 (Interface Body) modify the first paragraph as shown below:
As stated in the following rules, within an interface body,
can be defined operations and attributes . Those constructs are defined in the scope of the interface and exported (i.e., accessible outside the interface definition through their name scoped by the interface name).
In section 188.8.131.52.3.3.1 (Operations) replace "must" with "shall" in:
Operations that do not return a result
must specify 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
are still liable to receive one of the middleware-specific standard exceptions.
In section 184.108.40.206.3.3.2 (Attributes) replace "can" with "may" in the first sentence as shown:
can also be declared within an interface.
In the same section edit the bullet below as shown:
• For plain attributes, raises expressions
allow to indicate which the potential user-defined exceptions are when the attribute is read (getraises) and which the ones are when 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
are still liable to receive middleware-specific standard exceptions.
In section 220.127.116.11 (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
hosting interface). As opposed to 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 compilation error.
In section 18.104.22.168 (Purpose) modify the 2nd paragraph as shown below:
As opposed to 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 single interface .
In section 22.214.171.124.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 126.96.36.199.2 (Forward Declarations) modify the first sentence in the first paragraph as shown below:
Like interfaces, value types may be forward-declared, with the following syntax:
In section 188.8.131.52 (Explanations and Semantics) change "must" to "shall" in teh first bullet as shown below:
• A home declaration
must specify exactly one component type that it manages. Multiple homes may manage the same component type.
In section 184.108.40.206 (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 transition makes 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 its embedded constructs.
In section 220.127.116.11.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
compile errors 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 18.104.22.168.2 (Applying Annotations) modify the first bullet as shown below:
• The annotation name (<scoped_name>) prefixed with the at symbol
commercial at (@).
In the same section modify the second note as shown below:
Note – Annotations should not cause more
compile errors than strictly needed. Therefore, in case an unknown annotation is encountered, it should be simply ignored 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
compiler IDL-processor does not know which string_t is desired. Ambiguous declarations yield compilation errors.
In section 8.2.2 (Rules for Using Standardized Annotations) modify the bullets as shown below:
Must respect 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
must remain compliant with, the general one expressed here.
Must indicate the default behavior when no annotation is placed on an element that may be annotated. Note that this default is never identical to the default values provided for annotation members (when these default values exist). as the later values are just intended to be the most logical when the annotation is present.