Review normative conformance for spatial-types 1.0.0

As a maintainer of spatial-types,
I want to review the normative conformance of every spatial type considered fully implemented for 1.0.0,
so that the first stable release only claims complete support for spatial types whose implemented behavior is consistent with the applicable spatial standards.

Context

spatial-types 1.0.0 establishes the first stable baseline of the library.

Before its public contracts are reviewed and stabilized, the spatial model currently exposed by the library must be checked against the normative requirements applicable to the geometry types it claims to fully implement.

The objective of this Story is not to verify or implement the complete spatial model defined by the standards.

The review is limited to geometry types for which:

SpatialTypeImplementationStatus::isFullyImplemented($type) === true

at the time the review is performed.

Geometry types explicitly reported as not yet implemented are outside the scope of this review and do not block the 1.0.0 release solely because their implementation is incomplete.

The review must determine whether each fully implemented geometry type correctly represents the normative semantics and invariants that fall within the responsibilities of spatial-types.

Normative Sources

ISO/IEC 13249-3 is the primary normative reference for this review.

Applicable requirements from the spatial standards on which the LongitudeOne spatial model is based must also be considered where relevant, including:

• ISO 19107, Geographic information — Spatial schema;
• ISO 19111, Geographic information — Spatial referencing by coordinates;
• applicable OGC Simple Feature specifications;
• other normative sources explicitly adopted by the LongitudeOne spatial model.

When multiple normative sources describe the same behavior differently, the project's established normative arbitration rules must be applied.

The review must not silently resolve a normative ambiguity by selecting whichever behavior matches the current implementation.

Review Scope

For every geometry type reported as fully implemented, the review must identify and evaluate the normative requirements applicable to its representation by spatial-types.

The review must consider, where applicable:

• position in the geometry type hierarchy;
• instantiability;
• geometry structure;
• coordinate dimensions;
• EMPTY semantics;
• spatial reference semantics;
• component and collection constraints;
• point ordering;
• closure;
• simplicity;
• ring semantics;
• structural invariants;
• geometric invariants;
• consistency requirements between contained spatial objects;
• validity rules that belong to the responsibilities of spatial-types.

A requirement must only be attributed to spatial-types when enforcing or representing that requirement belongs to the responsibility of this library.

Requirements belonging to encoding, decoding, parsing, coordinate transformation or another LongitudeOne component must not be treated as missing spatial-types functionality.

Conformance Matrix

The review must produce a traceable conformance matrix.

For every applicable normative requirement, the matrix must identify at least:

The matrix must allow a maintainer to trace a normative requirement from its source to both its implementation and its automated verification.

Conformance Classification

Each reviewed requirement must be classified as one of the following:

Conformant

The implementation represents or enforces the applicable normative requirement and automated tests demonstrate the expected behavior.

Non-conformant

The implementation contradicts, incompletely implements or fails to enforce an applicable normative requirement that belongs to the responsibilities of spatial-types.

Normative ambiguity

The applicable normative sources do not provide a sufficiently unambiguous answer, or the adopted sources provide conflicting requirements.

The ambiguity must be explicitly documented and resolved before the affected public contract is stabilized.

Intentional divergence

The implementation deliberately differs from an applicable normative requirement for an identified architectural or compatibility reason.

The divergence must be explicit, justified and documented.

An existing behavior must not be classified as an intentional divergence merely to avoid changing it before 1.0.0.

Not applicable

The identified normative requirement does not belong to the responsibilities of spatial-types or does not apply to the reviewed geometry type.

The reason must be identifiable from the review.

Findings

This Story is an audit and conformance review.

A non-conformance discovered during the review must not be silently corrected as part of the review itself.

Each finding requiring implementation changes must be represented by a traceable issue or Story.

A finding must identify:

• the affected spatial type;
• the normative requirement;
• the observed implementation behavior;
• the expected behavior;
• the applicable normative source;
• the reason the finding blocks or does not block 1.0.0.

Blocking findings must be resolved before the public contracts of spatial-types 1.0.0 can be considered stable.

Test Coverage

Existing automated tests must be mapped to the normative requirements they demonstrate.

A passing test suite alone is not evidence of normative conformance.

When an applicable normative invariant has no automated test demonstrating its behavior, the missing coverage must be identified as a finding.

Tests introduced to resolve subsequent findings must demonstrate the normative behavior rather than reproduce the existing implementation behavior without reference to the requirement.

Acceptance Criteria

• Every geometry type reported as fully implemented is included in the review.
• Geometry types explicitly reported as not yet implemented are excluded from the mandatory 1.0.0 conformance review.
• Applicable normative requirements are identified for every reviewed geometry type.
• ISO/IEC 13249-3 is used as the primary normative reference.
• Applicable supporting ISO and OGC requirements are considered according to the project's normative arbitration rules.
• The review distinguishes requirements belonging to spatial-types from responsibilities belonging to other LongitudeOne libraries.
• A conformance matrix traces applicable normative requirements to their implementation and automated tests.
• Each reviewed requirement is classified as conformant, non-conformant, normative ambiguity, intentional divergence or not applicable.
• Existing automated tests are mapped to the normative requirements they demonstrate.
• Missing normative test coverage is identified.
• Every discovered non-conformance is represented by a traceable issue or Story when implementation changes are required.
• Every normative ambiguity affecting the 1.0.0 contract is explicitly documented and resolved before contract stabilization.
• Every intentional divergence is explicitly identified, justified and documented.
• No existing behavior is accepted solely because changing it would be inconvenient before 1.0.0.
• Every finding is classified as blocking or non-blocking for the 1.0.0 release.
• All blocking normative findings are resolved before this Story is considered complete.
• After resolution of blocking findings, every geometry reported as fully implemented has sufficient evidence to support that status.
• The resulting normative baseline is suitable as input for the subsequent public contract stabilization review.

Out of Scope

This Story does not:

• implement geometry types currently reported as not yet implemented;
• add geometry types solely to increase normative coverage;
• stabilize or freeze the public API;
• define the backward-compatibility policy for the 1.x lifecycle;
• perform the final 1.0.0 release validation;
• validate encoding or decoding behavior belonging to other LongitudeOne libraries;
• require implementation of the complete ISO/IEC 13249-3 spatial model.

Those concerns belong to subsequent Stories, other libraries or future minor releases.

Dependency

The geometry types required for the 1.0.0 functional scope, including CIRCULARSTRING and COMPOUNDCURVE, must be fully implemented before this review can be completed.

The successful completion of this Story is a prerequisite for the review and stabilization of the spatial-types 1.0.0 public contracts.