generated from coulomb/repo-seed
148 lines
4.6 KiB
Markdown
148 lines
4.6 KiB
Markdown
# INTENT
|
|
|
|
## Project Name
|
|
|
|
`open-cmis-tck`
|
|
|
|
## Purpose
|
|
|
|
`open-cmis-tck` provides a reusable CMIS compatibility test facility as a
|
|
service. Its first target is `kontextual-engine`, but the repository should be
|
|
useful for any CMIS-like repository that wants repeatable capability evidence
|
|
without embedding a Java/Maven TCK harness into the product repository itself.
|
|
|
|
The project turns CMIS capability claims into evidence:
|
|
|
|
- execute selected Apache Chemistry OpenCMIS TCK groups against a target access
|
|
point,
|
|
- capture results in compact machine-readable reports,
|
|
- classify failures by CMIS capability area,
|
|
- distinguish unsupported-by-design behavior from implementation defects,
|
|
- produce scorecard inputs that downstream projects can use for capability
|
|
planning.
|
|
|
|
## Product Thesis
|
|
|
|
CMIS interoperability is most useful when it is honest. A repository does not
|
|
need to support every optional CMIS 1.1 capability, but it must accurately
|
|
advertise what it supports and return stable diagnostics for everything else.
|
|
|
|
This project exists to make that honesty testable.
|
|
|
|
## Primary Use Case
|
|
|
|
Given a running CMIS Browser Binding access point, such as:
|
|
|
|
```text
|
|
http://127.0.0.1:8000/cmis/compat-tck/browser
|
|
```
|
|
|
|
the harness should:
|
|
|
|
1. load a target profile configuration,
|
|
2. run selected OpenCMIS TCK checks,
|
|
3. normalize raw TCK output,
|
|
4. map pass/fail/skip results to capability groups,
|
|
5. write a compact report that can be compared over time,
|
|
6. optionally expose the run and result through a small local service API.
|
|
|
|
## Intended Users
|
|
|
|
- Engine developers validating a CMIS adapter.
|
|
- Integration engineers checking a customer repository profile.
|
|
- Product owners tracking CMIS readiness over time.
|
|
- Automated agents that need structured evidence before adjusting a capability
|
|
scorecard.
|
|
|
|
## Scope
|
|
|
|
In scope:
|
|
|
|
- target profile configuration,
|
|
- OpenCMIS TCK orchestration,
|
|
- deterministic smoke probes for repository info and capability flags,
|
|
- result normalization,
|
|
- capability-group mapping,
|
|
- compact JSON and Markdown reports,
|
|
- service API for starting runs and reading results,
|
|
- historical result retention suitable for trend and scorecard updates,
|
|
- adapters for running against local development services.
|
|
|
|
Out of scope:
|
|
|
|
- implementing CMIS server behavior,
|
|
- replacing Apache Chemistry/OpenCMIS,
|
|
- claiming formal certification,
|
|
- embedding target-project domain knowledge into the harness core,
|
|
- requiring every consuming repository to use the same technology stack.
|
|
|
|
## Boundaries
|
|
|
|
`open-cmis-tck` is a test facility, not a CMIS implementation.
|
|
|
|
Target systems own:
|
|
|
|
- CMIS endpoints,
|
|
- repository data fixtures,
|
|
- authentication and authorization behavior,
|
|
- supported/unsupported capability decisions,
|
|
- product scorecards.
|
|
|
|
This project owns:
|
|
|
|
- harness execution,
|
|
- result normalization,
|
|
- capability-group classification,
|
|
- stable reporting contracts,
|
|
- optional local service orchestration.
|
|
|
|
## First Target Integration
|
|
|
|
The first target profile is `kontextual-engine` `compat-tck`.
|
|
|
|
Expected target URL:
|
|
|
|
```text
|
|
http://127.0.0.1:8000/cmis/compat-tck/browser
|
|
```
|
|
|
|
Initial expected posture:
|
|
|
|
- selected repository/type checks should pass,
|
|
- selected object/content checks should pass,
|
|
- navigation, query, ACL, and versioning checks may partially pass,
|
|
- AtomPub and Web Services are not target bindings,
|
|
- unsupported optional capabilities should be treated as expected skips or
|
|
explained gaps, not failures by default.
|
|
|
|
## Success Criteria
|
|
|
|
The project is useful when it can:
|
|
|
|
- run from a clean checkout with documented Java/Maven requirements,
|
|
- verify that a target CMIS endpoint is reachable before invoking the TCK,
|
|
- execute a selected TCK subset against a configured target,
|
|
- produce a normalized result file,
|
|
- map results to capability groups,
|
|
- identify unexpected failures separately from known gaps,
|
|
- support repeated runs without unbounded local data growth,
|
|
- provide enough evidence to update a downstream CMIS capability scorecard.
|
|
|
|
## Design Principles
|
|
|
|
- Keep target-specific policy outside the harness core.
|
|
- Make unsupported capabilities explicit and machine-readable.
|
|
- Prefer compact historical records over large raw logs.
|
|
- Preserve raw TCK output as optional artifacts, not the primary interface.
|
|
- Make local development easy before adding distributed execution.
|
|
- Treat score changes as evidence-driven, not aspirational.
|
|
|
|
## Initial Milestones
|
|
|
|
1. Repository foundation and target profile schema.
|
|
2. OpenCMIS TCK runner wrapper.
|
|
3. Result normalization and capability mapping.
|
|
4. Kontextual `compat-tck` target profile.
|
|
5. Optional service API for local run orchestration.
|
|
6. Scorecard export contract.
|