open-cmis-tck/INTENT.md

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:

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:

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.