Specyfikacja OSL

Specyfikacja OSL to normatywny kontrakt (RFC 2119). Definiuje każdy prymityw, każde pole i każdy kod błędu. Strona Koncepcje uczy modelu; specyfikacja go wiąże. Apache-2.0

W przygotowaniu

Bieżąca normatywna specyfikacja to v1.2-draft (ostatnio zmieniona 2026-06-04). Pełny tekst jest przygotowywany do publikacji pod spec.opendome.eu; autorytatywnym źródłem dziś jest platform/spec/osl/v1/SPEC.md w repozytorium.

Historia wersji

apiVersion: osl.opendome.eu/v1 obejmuje całą linię v1.x. Wersje minor są addytywne i zgodne przy odczycie; łamiące zmiany czekają na v2.

v1.0Baza

Fundament: nadzbiór MetricFlow (płaszczyzna ustrukturyzowana) + UnstructuredFacet (płaszczyzna nieustrukturyzowana) + most JointEntity oraz cztery poziomy conformance.

RFC 0002 · semantic_match · Accepted

v1.1Projekt

Model relacji i rozwiązywania: ustrukturyzowany↔ustrukturyzowany przez współdzielone encje, N-N przez mosty, uczciwe joiny ustrukturyzowany↔nieustrukturyzowany na autorytatywnych kluczach, multi-hop i szybkie rozwiązywanie.

RFC 0003 · Relationships & resolution

v1.22026-06Bieżąca · robocza

Operacjonalizuje RFC 0003: trawersacja L2, nadzorowane próbkowanie treści (ACL + redakcja po stronie serwera) i ujednolicona domain-mapa (wszystko jest Entity; mosty zwijają się do krawędzi). Poziomy conformance Lance + Governance się rozszerzają.

RFC 0003 · Implemented

v1.32026-07Następna

Jedna powierzchnia zapytań (OSL-SQL): /osl/query staje się jedynym endpointem konsumpcji, składając retrieval, joiny i trawersację w jeden semantyczny dialekt SQL — plus operatory projekcji. RFC 0002 jest zastąpione przez źródło relacji RETRIEVE.

RFC 0005 · OSL-SQL · DraftRFC 0004 · Projection operators · Draft

v2Przyszła

Zarezerwowana na łamiące zmiany i prace jawnie poza granicą v1.x (np. inferencja / rozumowanie treść↔treść).

Dziewięć prymitywów

SemanticModel, Metric, SavedQuery, TimeSpine, UnstructuredFacet, JointEntity, Lexicon, DataContract, PolicyBinding. Każdy niesie apiVersion: osl.opendome.eu/v1 oraz kind. JSON Schemy są publikowane jedna na prymityw plus master schema manifestu.

RFC

Zmiany merytoryczne przechodzą przez proces RFC.

#	Tytuł	Status
0002	Predykat semantic_match / MATCHES	Zastąpione
0003	Relacje, rozwiązywanie i odpytywalność	Zaimplementowane
0004	Operatory projekcji (encoder + opcjonalny decoder)	Szkic
0005	OSL-SQL — jedna powierzchnia zapytań	Szkic

Zasady projektowe (wiążące)

Jeśli propozycja łamie jedną z nich, jest odrzucana:

1. Pass-through MetricFlow jest święty. Każdy poprawny projekt dbt-sl jest poprawnym OSL.
2. Lance jest pierwszej kategorii, nie dodatkiem — ma własne prymitywy, schemę, błędy, lineage.
3. Klient deklaruje, silnik wykonuje. Specyfikacja mówi co istnieje, nigdy jak to działa.
4. Każda decyzja jest audytowalna — query, retrieval, decyzja PDP, wszystkie emitują OpenLineage.
5. Wersjonowanie to kontrakt. …/v1 nie złamie twojego YAML-a przez całą linię v1; łamiące zmiany czekają na v2.

Gwarancja wersjonowania

apiVersion: osl.opendome.eu/v1 to obietnica niełamania twojego YAML-a w całej linii v1. Endpointy mogą dodawać opcjonalne pola w obrębie v1.x; klienci muszą ignorować nierozpoznane pola. Cokolwiek zdeprecjonowanego w v1.x pozostaje funkcjonalne przez co najmniej dwie kolejne wersje minor; usunięcie wymaga v2, serwowanego obok v1 przez to okno.

Powiązane

• Poziomy conformance — Core, Lance, Lineage, Governance.
• Proces RFC — jak zaproponować zmianę.