[x] (1) Inconsistent use of conceptual model, Conceptual Model, CityGML, CityGML conceptual model, CityGML Conceptual Model etc. Should be consistent and perhaps also use the abbreviation "CM" for "conceptual model". I made this suggested edit in numerous places.
[x] (2) Inconsistent use of "specification" and "standard". All "specification" instances should be changed to "standard".
[x] (3) The "Conceptual Modelling" section could be significantly shortened with perhaps an explanation of the universe of discourse.
[x] (4) Section (Clause) 7 could be completely moved into a separate "Intro to CityGML 3.0" document.
[x] (5) There are "shalls" and "musts" scattered through the informative clauses. Should these be formal requirements? Or are they also stated as requirements in the normative sections of the draft standard?
[x] (6) The document uses the term, "Implementation Specification". Given that the OGC (and ISO, OASIS, etc) generates standards and given that 10 or so years ago the OGC members agreed that the OGC develops Implementation Standards, should this term be changed to "Implementation Standards"? I did not note all instances of the use of Implementation Standard as they are in every Requirement with "classes" as part of the URI.
[x] (7) I would suggest removing email addresses for the submitters.
[x] (8) Question about the use of “SHALL NOT”. Should this be rephrased into a “SHALL”? According to the Mod Spec: All requirements are identifiable as requirements. In OGC and ISO, this means use of ―normative‖ language, meaning the proper use of SHALL, SHOULD, CAN and MAY or similar wording in the passive voice. So, for example, Requirement 2 could be rephrased as “… SHALL include exterior boundaries only.”
2 Implementation Specification is the OGC term. There is no such thing as an OGC Implementation Standard. In all other cases where we refer to an approved standard, the term Standard is used. Specification is used when documents may not be approved standards (such as Implementation Specifications with a local scope.
4 An overview section is required by the OGC template. Furthermore, the SWG feels that this information is essential for understanding and the proper use of the standard.
6 Implementation Standard is not an OGC document type according to the OGC Definition Server. Implementation Specification is. Therefore, we have used the term specified by the OGC Definition Server and by association the OGC Naming Authority.
[x] (1) Inconsistent use of conceptual model, Conceptual Model, CityGML, CityGML conceptual model, CityGML Conceptual Model etc. Should be consistent and perhaps also use the abbreviation "CM" for "conceptual model". I made this suggested edit in numerous places.
[x] (2) Inconsistent use of "specification" and "standard". All "specification" instances should be changed to "standard".
[x] (3) The "Conceptual Modelling" section could be significantly shortened with perhaps an explanation of the universe of discourse.
[x] (4) Section (Clause) 7 could be completely moved into a separate "Intro to CityGML 3.0" document.
[x] (5) There are "shalls" and "musts" scattered through the informative clauses. Should these be formal requirements? Or are they also stated as requirements in the normative sections of the draft standard?
[x] (6) The document uses the term, "Implementation Specification". Given that the OGC (and ISO, OASIS, etc) generates standards and given that 10 or so years ago the OGC members agreed that the OGC develops Implementation Standards, should this term be changed to "Implementation Standards"? I did not note all instances of the use of Implementation Standard as they are in every Requirement with "classes" as part of the URI.
[x] (7) I would suggest removing email addresses for the submitters.
[x] (8) Question about the use of “SHALL NOT”. Should this be rephrased into a “SHALL”? According to the Mod Spec: All requirements are identifiable as requirements. In OGC and ISO, this means use of ―normative‖ language, meaning the proper use of SHALL, SHOULD, CAN and MAY or similar wording in the passive voice. So, for example, Requirement 2 could be rephrased as “… SHALL include exterior boundaries only.”
[x] (9) Carl Reeds redlines