Skip to content

docs(annex): add informative Conformance Test Corpus (T-16)#84

Open
aorzelskiGH wants to merge 1 commit into
IDTA-01004-3-1_Workingfrom
docs/conformance-test-corpus
Open

docs(annex): add informative Conformance Test Corpus (T-16)#84
aorzelskiGH wants to merge 1 commit into
IDTA-01004-3-1_Workingfrom
docs/conformance-test-corpus

Conversation

@aorzelskiGH
Copy link
Copy Markdown
Contributor

Summary

Add a new informative annex Conformance Test Corpus to IDTA-01004 with a structured, technology-neutral set of acceptance tests that implementations of the Access Rule Model can run to demonstrate conformance.

Problem

IDTA-01004 currently ships example rules but no structured catalogue of test / acceptance criteria. Reviewers and implementers rediscover the same edge cases on every release: default-deny behaviour, permit-overrides combination, treatment of inapplicable rules ($aasdesc in Repository profiles), runtime formula errors, filter combination semantics, RIGHTS mapping for PUT CREATE/UPDATE, supplementalSemanticIds scoping, etc.

Solution

  • Introduce documentation/IDTA-01004/modules/ROOT/pages/annex/conformance-test-corpus.adoc.
  • Organize tests into five groups: Rule loading, Rule evaluation, RIGHTS / operation mapping, Supplemental semantic IDs, Descriptor applicability per profile.
  • Each test has a stable ID (RULE.load.001, EVAL.combine.001, RIGHT.map.003, SUPP.rule.001, DESC.reg.001, ...), a one-line purpose, an expected behaviour and a requirement level.
  • Register the annex in nav.adoc.
  • Aligned with a matching corpus in IDTA-01002.

Affected files

  • documentation/IDTA-01004/modules/ROOT/pages/annex/conformance-test-corpus.adoc (new)
  • documentation/IDTA-01004/modules/ROOT/nav.adoc

Review notes

  • The corpus is explicitly marked informative. No normative surface area is changed; the MUST/SHOULD columns refer back to normative requirements defined in the Access Rule Model and the new Evaluation Semantics section (T-15).
  • Companion PR in aas-specs-api adds a matching corpus for the Query Language and HTTP/REST API.
  • Intent: a follow-up work stream can turn each row into an executable test case.

Refs: Review Finding T-16

Introduce a new annex that defines a structured, informative
set of acceptance tests for conforming implementations of the
Access Rule Model. The corpus covers:

- Rule loading and validation (JSON/BNF consistency)
- Rule evaluation (default deny, permit-overrides,
  inapplicable rules, formula runtime errors, filter
  combination)
- RIGHTS / operation mapping
- Supplemental semantic IDs in rule scopes
- Descriptor FieldIdentifier applicability per profile

Each test case has a stable ID, one-line purpose and expected
behaviour, so the corpus can be turned directly into an
executable conformance test suite. Aligned with the matching
corpus in IDTA-01002.

Refs: Review Finding T-16
Made-with: Cursor
| ID | Purpose | Expected

| RIGHT.map.001
| A `GET` on a resource MUST require the RIGHT `READ` according to xref:annex/operation-to-right-mapping.adoc[] of IDTA-01002.
This work is licensed under a [Creative Commons Attribution 4.0 International License](
https://creativecommons.org/licenses/by/4.0/).

SPDX-License-Identifier: CC-BY-4.0
////

[#conformance-test-corpus]
= Conformance Test Corpus (informative)

This annex defines an informative but structured set of *acceptance tests* for conforming implementations of the AAS Access Rule Model defined in this specification. The corpus is intentionally technology-neutral and worded as a set of test cases; an implementation is said to be conformant to a given area if it passes every required test case in that area.

The corpus is aligned with the conformance test corpus in IDTA-01002 Part 2: Application Programming Interfaces xref:bibliography.adoc#bib2[[2\]]. Tests that exercise shared formula grammar productions (logical expressions, comparisons, FieldIdentifiers, value literals, type casts, `$match`/`$and`/`$or`/`$not`) are normative for both specifications; IDTA-01002 is the single source of truth for those productions.
| ID | Purpose | Expected

| RIGHT.map.001
| A `GET` on a resource MUST require the RIGHT `READ` according to xref:annex/operation-to-right-mapping.adoc[] of IDTA-01002.
| Only rules granting `READ` on the matching ROUTE allow the request.

| RIGHT.map.002
| A `POST /.../operations/{idShortPath}/invoke` MUST require the RIGHT `EXECUTE`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants