Skip to content

okf: recommend relative cross-links over absolute (§5.1/§5.2)#165

Open
jeromeetienne wants to merge 1 commit into
GoogleCloudPlatform:mainfrom
jeromeetienne:main
Open

okf: recommend relative cross-links over absolute (§5.1/§5.2)#165
jeromeetienne wants to merge 1 commit into
GoogleCloudPlatform:mainfrom
jeromeetienne:main

Conversation

@jeromeetienne

Copy link
Copy Markdown

Fixes #157

Problem

SPEC §5.1 recommended /-prefixed absolute (bundle-relative) links, but
these only resolve correctly in an OKF-aware consumer. A raw renderer resolves
a leading / against its own root — the host origin in a browser, the repo
root on GitHub — which is not the bundle root once the bundle is nested as a
subdirectory within a larger repository (which §3 explicitly allows). In that
case the links mislink or 404, cutting against OKF's zero-tooling portability
goal.

The reference implementation had already voted against the spec on this:

  • The agent prompt (reference_instruction.md) forbids leading /
    ("Never start a link with / (that breaks GitHub rendering)").
  • Every cross-link in the shipped bundles/*/ concept files is relative.

So the spec recommended absolute → the agent forbade absolute → the bundles use
relative. The only thing out of step was the "recommended" label in the spec.

Change

Adopt resolution (1) from the issue — recommend relative links, keep absolute
as a supported OKF-aware-only form:

  • Swap §5.1 / §5.2 so relative links are §5.1 and marked (recommended),
    with the rationale that they resolve in any standard renderer (cat, browser,
    GitHub, editor preview) without OKF tooling. Noted drawback: breaks if a
    document moves.
  • Reframe absolute links as §5.2, documenting that they require an
    OKF-aware resolver
    and spelling out the browser/GitHub/nested-subdirectory
    failure mode.
  • Update the §4.3 / §4.4 examples to use the now-recommended relative form
    so the spec's own examples model the guidance.

Spec-text only — no code changes; this aligns the spec with what the reference
agent and bundles already do.

SPEC §5.1 recommended /-prefixed absolute (bundle-relative) links, but
these only resolve in an OKF-aware consumer. A raw renderer resolves a
leading / against its own root (host origin in a browser, repo root on
GitHub), which is not the bundle root once the bundle is nested as a
subdirectory within a larger repository (allowed by §3), so the links
mislink or 404.

The reference implementation had already voted against the spec: the
agent prompt forbids leading /, and every cross-link in the shipped
bundles is relative. This aligns the spec with that reality.

- Swap §5.1/§5.2 so relative links are §5.1 and marked recommended.
- Reframe absolute links as §5.2, documenting that they require an
  OKF-aware resolver and the browser/GitHub/nested-subdir failure mode.
- Update the §4.3/§4.4 examples to use the recommended relative form.
@google-cla

google-cla Bot commented Jul 1, 2026

Copy link
Copy Markdown

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@jeromeetienne

Copy link
Copy Markdown
Author

i signed the CLA

Screenshot 2026-07-01 at 05 57 35

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.

Absolute links (§5.1) don't resolve correctly in non-OKF-aware renderers

1 participant