IDL42 — Miscellaneous typos and readability improvements

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 such that it can be referenced by for other specifications to reference and . It 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:

1. Future specifications that use Any future specification using IDL shall reference this IDL standard or a future revision thereof.
2. Future revisions of current specifications using that use IDL may reference this IDL standard or a future revision thereof.
3. Reference to this standard must shall result in a selection of building blocks possibly complemented by groups of annotations.
a. All selected building blocks shall must be supported entirely.
b. Selected annotations shall must be either supported as described in ‎8.2.2 Rules for Using Standardized Annotations, or fully ignored. In the latter case, the IDL-dependent 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 unambiguously specifying unambiguous specification of the
interfaces that client objects may use and (server) object implementations provide as well as all needed related constructs such as exceptions or and 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 actual programs that use these interfaces or create the associated data-types 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 constructs to a programming language construct will depend on the facilities available in the that programming language. For example, an IDL exception might be mapped to a structure in a language that has no notion of exception exceptions, 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 shall 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 new operator (::+) has been added. This operator allows adding alternatives to an existing definition (assuming x ::= y, x ::+ z means actually x ::= y | z). For example, assuming the rule x ::= y, the rule x :: z shall be interpreted as x ::= y | z.

In Section 7.2.6.2.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, shall be treated as an error result in a compile-time diagnostic.

In Section 7.2.6.2.2 (Escape Sequences to Represent Character Literals) change the two occurrences of "must" to "shall" as shown below:
Nongraphic characters shall must be represented using escape sequences as defined below in Table ‎7 9. Note that escape sequences shall must be used to represent single quote and backslash characters in character literals.

In Section 7.4.1.1 (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 contains the syntax rules that allow defining most data types with what allows and the syntax rules that allow IDL basic structuring (i.e., modules). and, because Since it is the only mandatory building block which is mandatory, it also contains the root nonterminal <specification> for the grammar itself.

In Section 7.4.1.4.3 (Constants) first paragraph, change "must" to "shall" as shown below.
Well-formed constants must shall follow the following rules:

In Section 7.4.1.4.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 7.4.1.4.4 (Data Types) Change "can" to "may" in the first sentence as shown below:
A data type can may be either a simple type or a constructed one. Those different kinds are detailed in the following clauses.

In section 7.4.1.4.4.1 (Simple Types) replace the first bullet:
• Basic types that basically represent numbers and characters and fully pre-exist any IDL specification.
With:
• 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, anonymous types, that is, types actual the type resulting from an instantiation of a template type cannot be used directly as is (anonymously). Instead, prior to any use, template types must 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 using through a scoped name, in all other cases:

In section 7.4.1.4.4.1.1 (Basic Types) Edit the first paragraph as shown below:
Basic types are pre-existing types that represent numbers or characters. The set of basic types is They are defined by the following rules:

In section 7.4.1.4.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.
With:
If this rule is violated it shall be treated as an error

In section 7.4.1.4.4.4 (Native Types) modify the second paragraph as shown below:
As stated in the following rules, declaring a native type consist in just is done prefixing the type name (<simple_declarator>) with the native keyword:

In section 7.4.2.4 (Explanations and Semantics) edit the second paragraph as shown below:
An any logically contains a value and some means that specifies to specify the actual type of the value. This means However, the specific way in which the actual type is defined 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 7.4.3.4.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 shall be 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 shall be will be able to access the values of those members when such an exception is raised. If no members are specified, no additional information shall be is accessible when such an exception is raised.

In the same section, last paragraph, remove the word "thereafter"

In section 7.4.3.4.3 (Interfaces) modify the last sentence of the 2nd paragraph as shown:
An interface may also be declared with no definition with using a forward declaration (<interface_forward_dcl>).

In section 7.4.3.4.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 7.4.3.4.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 can be defined. Those constructs are defined in the scope of the interface and exported (i.e., accessible outside the interface definition using through their name scoped by the interface name).

In section 7.4.3.4.3.3.1 (Operations) replace "must" with "shall" in:
Operations that do not return a result shall 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 may are still liable to receive raise one of the middleware-specific standard exceptions.

In section 7.4.3.4.3.3.2 (Attributes) replace "can" with "may" in the first sentence as shown:
Attributes may 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 of the potential user-defined exceptions may be raised 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 may are still raise liable to receive middleware-specific standard exceptions.

In section 7.4.4.4 (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 inside an interface declaration.

In the same section modify the paragraph as shown below:
All those elements are exported (i.e., visible under the scope of their enclosing hosting interface). In contrast 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 shall be treated as an error.

In section 7.4.5.1 (Purpose) modify the 2nd paragraph as shown below:
In contrast 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 Single interface support.

In section 7.4.5.4.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 7.4.5.4.2 (Forward Declarations) modify the first sentence in the first paragraph as shown below:
Similar to Like interfaces, value types may be forward-declared, with the following syntax:

In section 7.4.9.4 (Explanations and Semantics) change "must" to "shall" in teh first bullet as shown below:
• A home declaration must shall specify exactly one component type that it manages. Multiple homes may manage the same component type.

In section 7.4.12.1 (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 transitively 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 Instantiation of the template module instantiates all the embedded constructs.

In section 7.4.15.4.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 the IDL-processing tools 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 IDL-processing errors than strictly needed. Therefore, in case of multiple definitions of the same annotation in one IDL specification , the the IDL-processing tools compiler should accept them, provided that they are consistent. In contrast, malformed definitions shall be treated as an error In return, compilers should raise an error in case of malformed definitions.

In section 7.4.15.4.2 (Applying Annotations) modify the first bullet as shown below:
• The annotation name (<scoped_name>) prefixed with the at symbol commercial at (@), also known as commercial at.

In the same section modify the second note as shown below:
Note – Annotations should not cause more compile IDL-processing errors than strictly needed. Therefore, in case an unknown annotation is encountered, it should be simply ignored by the IDL-processing tools compiler. In contrast, malformed definitions shall be treated as an error 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 shall be treated as yield compilation errors.

In section 8.2.2 (Rules for Using Standardized Annotations) modify the bullets as shown below:
• Shall 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 shall must remain compliant with, the general one expressed here.

• Shall 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 not the same as the default values defined provided for the annotation members (when these default values exist). This is because as the later values are just intended to be the most logical values when the annotation is present.

Fix the typos and make the improvements suggested in the issue description.

Apply the changes suggested in the issue description.