In Clause 10, the base URL of all displayed OWL code is spelled "exampe.com", which should be "example.com". The same misspelling is present in the machine-readable files. The URLs shall be corrected and the machine-readable files re-issued. This will also change the front page of the specification.

While at it, Annex B (List of Machine-Readable Files) shall be deleted. This function is handled by the OMG Specification Catalog.

In Clause 10, the base URL is misspelled

Indeed, "example.com" is misspelled as "exampe.com" throughout the whole Clause 10. While technically not worn, it looks unprofessional.

Correct all occurrences of "exampe.com" throughout Clause 10, correct also the machine readable files and re-release the whole set.

Delete Annex B, its function has been taken-over by the specification catalog.

The specification uses OWL Turtle Syntax and the QVT Graphical Syntax in normative clauses, therefore references to these specifications in Clause 3.1 (Normative References) are required.

In this context, the introductory paragraphs of Clauses 8 and 9 should be reworded to eliminate the explicit mentioning of XSLT and RDFXML. For the mapping specification it is irrelevant with which technology the definitions were produced. Regarding RDFXML, while it might be a transitional representation of the OWL output, it should be removed from the text since this transitional form never shows up in the specification.

References to, and explanation of Usage for Turtle and QVT

RDF/XML is not used in this specification, all OWL code is in RDF Turtle syntax, therefore swap the RDF 1.1 Turtle reference in, replacing RDF/XML.

The QVT graphical notation for transformations is used in the code displays, therefore a normative reference for QVT shall be added.

As a consequence, the lead-in paragraphs for Clause 8 and Clause 9 shall be changed accordingly.

In Clause 9.2.5 after the code display for "ClassA3 / attr3" change the phrase "owl:allVal esFrom" to "owl:allValuesFrom"

Phrase owl:allValuesFrom garbled

In Clause 9.2.5, subsection "Properties typed by Flat Literal Type", after the code display for ClassA3 - attr3, the phrase "owl:allValuesFrom" is misspelled.

In the first sentence after the code display, insert the word "link" after "This represents the sequence number of the current"

*Insert missing word *

Insert the missing word "link" into the description.

Improve the document formatting so that captions are not flowing to the next page following a figure or code display.

Correct the following captions:
Clause 8.2.2: "Class" => "Stereotype"
Clause 8.2.6: "Association" => "AssociationClass"

In Clause 9.2.5, subsection "Properties typed by Structure or Class Types", reword the second paragraph following the code display (without changing its meaning) so that it does not overflow into the page margin.

Improve Formatting and Correct Captions

Group code displays with corresponding captions to ensure code displays and captions appear always on the same page.

Correct caption text for 8.2.2 Stereotype and 8.2.6 AssociationClass

Reword second paragraph in clause 9.2.5, subsection "Properties typed by Structured or Class Types" to avoid overflow into page margin.

QVTo has one form of mapping overloading provided by disjuncts. This is poorly specified.

It probably has another provided by name collision. This is unspecified.

What are the QVTo mapping overloading semantics?

QVTo has one form of mapping overloading provided by disjuncts. This is poorly specified.

It probably has another provided by name collision. This is unspecified.

The <rulerefs> between mappings has no defined semantics.

Presumably:

<package-name>*::<transformation-name>::<context-type>::<mapping-name>

allowing <package-name>*::<transformation-name> to be omitted defauklting to the current transdformation, and, preserving the current example semantics, resolving an omitted <context-type> by serching all mapping names in the transformation.

Undefined rulerefs

The <rulerefs> between mappings has no defined semantics.

Presumably:

<package-name>*::<transformation-name>::<context-type>::<mapping-name>

allowing <package-name>*::<transformation-name> to be omitted defauklting to the current transdformation, and, preserving the current example semantics, resolving an omitted <context-type> by serching all mapping names in the transformation.

Issue Links

Discussion

Since <mapping_id> needs definition, we can take the opportunity to rename the strange <rulerefs>.

8.2.2.10 VariableInitExp says

A variable may not declare an initialization value.

when surely it means

A variable may omit an initialization value.

Unfortunate VariableInitExp wording for missing initializer

8.2.2.10 VariableInitExp says

A variable may not declare an initialization value.

when surely it means

A variable may omit an initialization value.

The return type of xselectOne, xcollectselectOne returns a SEquence rather than an optional value.

xselectOne, xcollectselectOne is Sequence of One not One

The return type of xselectOne, xcollectselectOne returns a Sequence rather than an optional value.

Discussion

QVT13-34 revealed numerous errors in the pseudocode. This error is just one of many fixed by its resolution.

For imported compilation units, the specification should clearly state what happens if there is no corresponding ModuleImport for any of the modules included inside the imported unit.

The Eclipse QVTo implementation applies extends semantics by default. A very bad idea, because it leads to undesired extensions and overridings (especially in case of multiple modules per unit).

Using access as a default is a much better idea, but maybe clutters the namespaces at AST level with needless module imports.

Therefore applying neither access nor extends could be another good idea, but lacks a helpful default behavior.

Unspecified handling of imports without access/extends

For imported compilation units, the specification should clearly state what happens if there is no corresponding ModuleImport for any of the modules included inside the imported unit.

The Eclipse QVTo implementation applies extends semantics by default. A very bad idea, because it leads to undesired extensions and overridings (especially in case of multiple modules per unit).

Using access as a default is a much better idea, but maybe clutters the namespaces at AST level with needless module imports.

Therefore applying neither access nor extends could be another good idea, but lacks a helpful default behavior.

Discussion

Following some off-JIRA correspondence, the original issue is clearer and simpler.

The 8.2.1.4 words say that ImportKind has only two possibilities. But the words and model omit a [1] multiplicity or defaultValue so that null is a third possibility. The grammar also permits a missing ImportKind.

So as suggested we could introduce a third null semantics, or define one of access/extends as the default.

I see no benefit in a third semantics.

"extends" is a very serious mutating activity, not a default.

"access" is harmless and non-mutating. Hardly AST clutter. If the user didn't want the names the user should not have specified an import.

Let "access" be the default.

The prohibition on creation or update of instances in helpers has no justification. Why?

Allow object creation in helpers

The prohibition on creation or update of instances in helpers has no justification. Why?

Discussion

This came up while clarifying wording for QVT13-33.

The prohibition is presumably intended to ensure that all object creation has a corresponding trace record. A good idea but beyond the pragmatic integrity of QVTo. Untraced objects can be created in mappings anyway, so prohibiting their creation in helpers is just an unhelpful restriction on programming flexibility.

There is currently no way for an overriding operation to call its overridden super implementation. ImperativeOCL should provide something similar to the 'super' reference which is available in Java.

Calling the super implementation of an overriding operation

There is currently no way for an overriding operation to call its overridden super implementation. ImperativeOCL should provide something similar to the 'super' reference which is available in Java.

Discussion

QVT13-93 clarifies the concept of a mapping identifier. An arbitrary mapping may therefore be called:

self.map My::Tx::Your::Type::doIt(withSomething);

The following helper from the specification is a NOP, because List::append has no side effect in QVT 1.2.

helper Package::computeCandidates(inout list:List) : List

Therefore the snippet should rather use List::add.

Incorrect use of side-effect free append in example

The following helper from the specification is a NOP, because List::append has no side effect in QVT 1.2.

helper Package::computeCandidates(inout list:List) : List

Therefore the snippet should rather use List::add.

Discussion

Yes

The full names of the QVT languages are a bit cumbersome and so QVTc/QVTo/QVTr are often found in non-OMG usage.

Suggest that the QVT specification at least define them and perhaps use them a little too.

QVTc/QVTo/QVTr acronyms

The full names of the QVT languages are a bit cumbersome and so QVTc/QVTo/QVTr are often found in non-OMG usage.

Suggest that the QVT specification at least define them and perhaps use them a little too.

It is hard to understand relationship between this sub clause and Figure 12-1 through 12-4. Because there is no sentence as explaining Figure 12-1 through 12-4. Add sentences to explain relationship to Figure 12-1 through 12-4.

No Data Available

The first sentence implies that certain changes are specified in this clause, but there is no specification. However, unless the current document is intended as a delta document with respect to some earlier standard, which does not appear to be the case, then identifying such changes in the body of the standard is not appropriate. Indicate clearly the clauses in which the differences are described. If the differences are described, consider moving the information to an informative annex.

Proposed Resolution by NB:
Indicate clearly the clauses in which the differences are described. If the differences
are described, consider moving the information to an informative annex.
Discussion:
Delete subclause 8.4.
Disposition: Merged with issue 18661

"remove(object: Object): Object
Removes the specified object from the collection. Returns true if the object was removed."

Maybe the operation should return a Boolean.

Agreed. Correct the operation signature to return Boolean

References in MOF Core to Infrastructure/Superstructure are obsolete, as are Figures 7.1, 12.1, 14.1 .

Agreed. The resolution for issue 15608 removed all remaining references to
Infrastructure and Superstructure (where applicable) and updated all affected
diagrams. However the figures listed above were deemed valuable and have
therefore been updated and not removed.
Disposition: Merged with 15608

This is a condensed issue covering the individual comments recorded in the consecutive issues 17631 to 17717, which shall be resolved as Duplicate/Merged with this issue, which was created to make the document revision process more manageable.

Resolve the ISO PAS comments sequentially throughout the document

Annex C is only described as an agreement for OMG. Delete Annex C.

No Data Available

It is hard to understand relationship between this sub clause and Figure 15-1. Because there is no sentence as explaining Figure 15-1. Add sentences to explain relationship to Figure 15-1.

No Data Available

Annexes should be referred as Annex A,B,C. Change A, B, C to Annex A, Annex B, Annex C.

No Data Available

Issue as “migration from MOF, v1.4” is not needed because it is informative. Move to an annex or delete this clause.

No Data Available

This diagram uses a color. Get rid of the color.

No Data Available

Annex B is not needed because it is not relevant to this standard. Delete Annex B.

No Data Available

Annex A is not adequate as normative. Because it refers external documents that are not standardized. Put enough description in Annex A or change to an informative annex.

No Data Available

Caption is missing for a diagram in this sub clause. Add a caption.

No Data Available

Title “Notes” is not suitable for clauses. Change to a note format defined in ISO/IEC Directive Part 2.

No Data Available

In this the last line, there is "Figure 11.1". However, the figure label is "Figure 11-1". Be consistent with each other.

No Data Available

It is hard to understand relationship between this sub clause and Figure 14-1. Because there is no sentence as explaining Figure 14-1. Add sentences to explain relationship to Figure 14-1.

No Data Available

It is hard to understand relationship between this sub clause and Figure 14-1. Because there is no sentence as explaining Figure 14-1. Add sentences to explain relationship to Figure 14-1.

No Data Available

Sentences of this part header are not needed. Delete this part.

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
MOF1.4 --> ISO/IEC19502

No Data Available

Three packages as Reflection, Identifiers and Extension are merged. However, four packages are merged in Figure 14-1. Add “Common” as a fourth package.

No Data Available

In this the first line, there is "Figure 14.2". However, there is no figure labeled "Figure 14.2". Refer an existing figure.

No Data Available

There are three figures in Page 49, 50 and 53 as same number as 14-1. Renumber a second figure as 14-2 and a third figure as 14-3.

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
MOF1.4 --> ISO/IEC19502

No Data Available

This designates "None". This prescription is insufficient. Describe adequately.

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”

MOF1.4 ?ISO/IEC19502

No Data Available

The sentence should define a grammatical prescription. However this definition is constraint and insufficient. Replace the text with precise one.

No Data Available

It is hard to understand relationship between this sub-clause and figures as Figure 13-1 and 13-2. Because there is no sentence as explaining Figure 13-1 and 13-2. Add sentences to explain relationship to Figure 13-1 and 13-2.

No Data Available

There are references to W3C documents in the Term [5]. These are normative reference. Besides, this definition style is different from UML 2.4.1 and OCL 2.4.1. Be consistent with UML 2.4.1 and OCL 2.4.1

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
MOF1.4 --> ISO/IEC19502

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
MOF1.4 --> ISO/IEC19502

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
MOF1.4 --> ISO/IEC19502

No Data Available

These diagrams as Figure 12-1, 12-2, 12-3 and 12-4 are filled with color. However, these colors are meaningless. Get rid of the color.

No Data Available

There are two figures in Page 32 and 33 as same number as 12-1. Renumber a second figure as 12-3 and following figures in order.

No Data Available

It is hard to understand relationship between this sub clause and Figure 12-1. Because there is no sentence as explaining Figure 12-1. Add sentences to explain relationship to Figure 12-1.

No Data Available

No need subtitle as “General.” Because title “The MOF Model” is enough to understand the meaning of this part. Delete subtitle “General.”

No Data Available

It is hard to understand relationship between this sub clause and Figure 11-1. Because there is no sentence as explaining Figure 11-11. Add sentences to explain relationship to Figure 11-1.

No Data Available

Three packages as Reflection, Identifiers and Extension are merged. However, four packages are merged in Figure 12-1. Add “Common” as a fourth package.

No Data Available

This clause “introduction” explains an overview of EMOF model. However, there are many sub clauses “general” as explaining overviews. Change “introduction” to “general.”

No Data Available

It is hard to identify a clause for MOF Model’s requirements and use UML 2 Infrastructure. Change to “CMOF Abstract Semantics.”

Reflective Collection and Reflective Sequence are defined in Common package. However, they are described as a part of Identifiers Package. Change a sub clause as 10.5 Reflective Collection and 10.6 Reflective Sequence to a sub clause as 11.1 and 11.2.

No Data Available

There are two diagrams in one Figure 10-1. Split it into two figures 10-3 as classes and 10-4 as relationship between packages.

No Data Available

Sub clause MOF::Common describes for Common Package. However, other descriptions for packages are described in clauses. Change a sub clause as 10.4 to a clause as 11 and renumber following clauses.

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”

No Data Available

It is hard to understand relationship between this sub clause and Figure 10-1. Because there is no sentence as explaining Figure 10-1. Add sentences to explain relationship to Figure 10-1

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”

No Data Available

Split it into two figures 10-1 as classes and 10-2 as relationship between packages.

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes

No Data Available

There are two diagrams in one Figure 9-1. Split it into two figures 9-1 as classes and 9-2 as relationship between packages.

No Data Available

It is hard to understand relationship between this sub clause and Figure 9-1. Because there is no sentence as explaining Figure 9-1.Add sentences to explain relationship to Figure 9-1.

No Data Available

Four packages are described in this part rather than three as Reflection, Identifiers and Extension.

No Data Available

There are two figures in Page 21 and 23 as same number as 10-1. Renumber a second figure as 10-3.

No Data Available

No need subtitle as “General.” Because title “Capabilities” is enough to understand the meaning of this part. Delete subtitle “General.”

No Data Available

MOF 1.4 and 2.4.1 are independent specifications. “Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”.
Use ISO/IEC19502 for MOF 1.4

No Data Available

There are unexplained terms for language formalism as Properties, Operations, Constrains, Semantics, Rationale, and so on.

No Data Available

To change a title to “MOF 2 Design Requirements.” There must be some statements to be ISO standards.. MOF1.4 had become ISO.

No Data Available

There are descriptions of "UML2.0", "MOF2.0". And, "UML2", "MOF2", within this standard (for example Section 8 and etc.). These designations are ambiguous.

No Data Available

No Data Available

In this the last line, there is "Figure 7.1". However, the figure label is "Figure 7-1". Make it consistent

No Data Available

Delete the title “7.1 General”.
Then Re-numbering must be needed.

No Data Available

There is no reference of other specifications as UML. However, many symbols of UML are used. To add sentences for reference of symbols used in this specification

No Data Available

Terms and concepts that were used in this document should be defined here.

No Data Available

No need subtitle as “General Information.” Because title “Introduction” is enough to understand the meaning of this part.

No Data Available