Several clarifications to the text requested

[chris-little]

@joanma747 identified several areas of confusion requiring improvements to the text. These have been split into 8 separate sub-issues: • The reference to the modular spec is confusing and should not be there: "This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec." In my opinion the document ignores de modspec and does not define requirements ore requirements classes etc. This is "ok" for a community standard but then lets not create false expectations. We will remove and add sentence about the schema • The definition section needs to be improved. Some of the definitions are irrelevant such as RFC are there and definition fundamental to understand the model such as "domain" or "range" are not there. Agreed. Will add defs. • Title of section 6 sounds a bit odd to me: "FULL SPECIFICATION: NORMATIVE AND INFORMATIVE INTERMIXED". how a single chapter can be the full spec?. Then what is the rest?. I think we could retitle this as “FULL SPECIFICATION: NORMATIVE with Informative Examples” • The section "6.6.2. NdArray Objects" defines n dimensional datacube. I tried hard to understand the order of the values with respect the axes Names but I'm still unsure. This is a very important aspect and should be crystal clear. o The multiplication of the shape numbers give you the exact number of values but this is not written. o About the number encoding: "Note that common JSON implementations use 64-bit floating point numbers as data type for "values", therefore precision has to be taken into account. For example, only integers within the extent [-2^32, 2^32] can be accurately represented with 64-bit floating point numbers." is not consistent with the IETF RFC. I suggest to align it: “This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers IEEE754 is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available. Note that when such software is used, numbers that are integers and are in the range [-(253)+1, (253)-1] are interoperable in the sense that implementations will agree exactly on their numeric values." • "The CoverageJSON media type SHALL be application/prs.coverage+json". Can you clarify what prs means? Done verbally. We can point to the IETF reference. • I do not like the sentence: "Future improvements have been identified, such as the use of multiple time dimensions, or to use JSON-LD V1.1 which may give better compatibility with the OGC Coverage Implementation Schema (CIS) Version 1.1". o I do not understand why JSON-LD 1.1 will give better compatibility with CIS. The compatibility with CIS is another issue altogether. JSON-LD1.0 only allows links from top level objects, for performance reasons. JSON-LD1.1 potentially allows links from deeply nested objects, as used in CIS. Whether this is performant is not clear. Let us delete the section, and replace with a pointer to projects on repo. • Can you add CIS to the bibliography? Yes • The document could benefit from some class diagram in UML. This will make the similarities and differences with CIS more visible and clear the path to a possible convergence in the future. Added issue for future work.

[chris-little]

This issue can be closed when all the sub-issues have been closed.

[chris-little]

@joanma747 All your issues raised in the OAB have been addressed, hopefully to your satisfaction, and the spec modified, so now closing this issue.