Grundlegender Ablauf
- Der Agent schreibt ein .owx-Quellpaket.
ow a2ui checkvalidiert den geschlossenen Autorenvertrag.ow a2ui compileerzeugt das typisierte Render-Document-JSON-Artefakt.ow publishsendet das validierte Artefakt an OWL Compose Hosted.
OWX ist die einzige Autorquelle. Das kompilierte JSON ist eine Ausgabe, keine zweite Autorensprache. Nicht unterstütztes XML, beliebiges HTML, JavaScript, rohes Markdown und manuell bearbeitete kompilierte Dateien liegen außerhalb des Vertrags.
Tutorial
Erstelle ein OWX-Dokument Schritt für Schritt.
Dieses Tutorial beginnt mit einem minimalen Dokument, ergänzt Daten, Abfragen, Facts und Darstellungskomponenten und führt anschließend durch Prüfung, Kompilierung und Veröffentlichung. Für genaue Nachschlagen stehen am Ende die Node-Tabelle und der Maschinenvertrag.
1. Mit dem Dokumentgerüst beginnen
Jedes Werk hat genau eine ow-document-Wurzel. Deklariere die exakte Protokollversion und Metadaten und lege leserorientierte Inhalte in Sections und typisierten Nodes ab.
<ow-document owx-version="1" title="Decision brief" canvas="briefing">
<section id="overview">
<ow-text id="summary" title="Decision brief" title-level="1" body="A concise conclusion." />
</section>
</ow-document>Der title der Wurzel ist Metadaten. Eine sichtbare Überschrift ist ein explizites ow-text-Kind; wiederhole denselben Titel nicht als freien Text.
2. Daten, Abfragen und Facts ergänzen
Halte Belege typisiert und reproduzierbar. Lade ein Dataset, transformiere es mit einer Query und stelle über einen Fact den exakten Wert bereit, den eine Komponente anzeigen soll.
<ow-document owx-version="1" title="Regional revenue">
<ow-data id="sales" src="./sales.csv" schema="./sales.toml" />
<ow-query id="sales-by-region" from="dataset:sales">
<ow-group by="region" />
<ow-aggregate name="revenue" operation="sum" field="revenue" />
</ow-query>
<ow-fact id="total-revenue" query="query:sales-by-region" field="revenue" />
</ow-document>Queries beschreiben Transformationen; Facts benennen die Werte, die Präsentations-Nodes verbrauchen. Bearbeite das kompilierte JSON nicht von Hand, um Zahlen zu ändern.
3. Unterstützte Komponenten platzieren
Baue die Leseransicht mit typisierten Layout- und Präsentations-Nodes. Binde Metriken, Charts und Tabellen an eine geprüfte Query oder einen Fact, statt dieselbe Aussage im Text zu wiederholen.
<section id="summary">
<ow-grid id="cards">
<ow-metric id="revenue" fact="fact:total-revenue" label="Revenue" />
<ow-chart id="revenue-chart" data="query:sales-by-region" type="bar" title="Revenue by region" summary="Compare revenue by region." />
<ow-table id="regional-table" data="query:sales-by-region" title="By region" />
</ow-grid>
</section>Wähle die Komponente nach der Frage des Lesers. Chart, Tabelle, Karte oder Graph sind nur nützlich, wenn Datenbindung und visuelle Rolle ausdrücklich sind.
4. Validieren, kompilieren und veröffentlichen
Das Quellpaket ist die bearbeitbare Quelle. Führe die Prüfungen der Reihe nach aus, prüfe das kompilierte Ergebnis und veröffentliche nur das validierte Render-Document-JSON-Artefakt.
ow a2ui check ./artifact/document.owx
ow a2ui fmt ./artifact/document.owx
ow a2ui compile ./artifact/document.owx --output ./artifact/document.json
ow a2ui digest ./artifact/document.json
ow publish ./artifact/document.json --no-open`check` prüft Syntax, Typen, Bindings, Catalog-Zugehörigkeit und Ressourcengrenzen. `compile` erzeugt das Artefakt, `digest` protokolliert seine exakte Identität und `publish` sendet es an Hosted.
Häufige Nodes auf einen Blick
Diese Nodes verwendet ein Agent am häufigsten. Jede Signatur zeigt die Attribute, die den Node normalerweise identifizieren; für alle optionalen Felder und Kindbeziehungen brauchst du den generierten Catalog.
Dokumentstruktur
Beginne mit der Wurzel und gib jeder sichtbaren Region einen echten Parent.
| Tag | Signatur | Verwendung |
|---|---|---|
ow-document | <ow-document owx-version title> | Die einzige Autorenwurzel und Protokollgrenze. |
section | <section id> | Eine semantische Seitenregion mit stabiler id. |
ow-text | <ow-text id title title-level> | Sichtbare Überschrift, Vorspann, Text oder Fact-Referenzen. |
ow-grid | <ow-grid id class> | Responsiver Layout-Container für typisierte Kinder. |
Daten und Belege
Mache den Weg vom Quellmaterial zum angezeigten Wert prüfbar.
| Tag | Signatur | Verwendung |
|---|---|---|
ow-data | <ow-data id src schema> | Typisiertes Dataset aus einer paketlokalen Quelle. |
ow-query | <ow-query id from> | Deterministische Pipeline für Filter, Ableitungen, Gruppen oder Aggregate. |
ow-fact | <ow-fact id query field> | Benannter Wert aus Query und Feld. |
ow-sources | <ow-sources src> | Mit dem Werk verknüpftes Quellenregister. |
Darstellung
Verwende eine typisierte Visualisierung nur für eine konkrete Leserfrage.
| Tag | Signatur | Verwendung |
|---|---|---|
ow-metric | <ow-metric id fact label> | Hervorgehobener Wert, der an einen Fact gebunden ist. |
ow-chart | <ow-chart id data type title summary> | An eine Query gebundener Chart mit explizitem Typ. |
ow-table | <ow-table id data> | Tabellenansicht eines geprüften Datasets oder einer Query. |
ow-map | <ow-map id data place country level join value title summary> | Geografische Ansicht mit Orts- und Wertfeldern. |
Beziehungen und Interaktion
Deklariere Topologie und begrenzten Zustand statt beliebigem HTML.
| Tag | Signatur | Verwendung |
|---|---|---|
ow-graph | <ow-graph id layout direction> | Topologie-bewusster Graph-Container. |
ow-graph-node | <ow-graph-node id label> | Beschrifteter Node in einem ow-graph. |
ow-connector | <ow-connector from to> | Typisierte Beziehung zwischen bekannten Endpunkten. |
ow-view-switcher | <ow-view-switcher id label> | Begrenzte Menge benannter Ansichten. |
Unterstützende Inhalte
Nutze paketlokale Medien und ausdrückliche Zusatzblöcke.
| Tag | Signatur | Verwendung |
|---|---|---|
ow-media | <ow-media id file alt> | Paketlokales Bild mit aussagekräftigem alt-Text. |
ow-code | <ow-code id language value> | Codeblock mit expliziter Sprache. |
ow-list | <ow-list id> | Geordnete oder ungeordnete typisierte Liste. |
ow-callout | <ow-callout id title body> | Beschrifteter Hinweis oder Entscheidungs-Callout. |
Regeln für ein sicheres Ergebnis
- Der Autoren-Catalog ist geschlossen: Ein nicht registriertes ow-* Tag oder Attribut ist keine Ersatzkomponente.
- Bewahre eine einzige .owx-Quelle. Kompiliertes JSON ist ein generiertes Artefakt, keine zweite Autorensprache.
- Binde externe Fakten über typisierte Daten, Queries und Facts; erfinde keine Werte, um das Layout zu füllen.
- Verwende nur paketlokale Medien und unterstützte Klassen. Beliebiges HTML, JavaScript, entfernte Ressourcen und Pfad-Traversal werden abgewiesen.
Unterstützter OWX-Ablauf
Leitfaden für Maschinenvertrag und Audit
Das Tutorial oben ist der normale Einstieg. Die folgenden Links führen zum unterstützten Ablauf, zur Node-Tabelle dieser Seite sowie zu den gepflegten CLI- und Autorenleitfäden, wenn ein Agent oder Reviewer Namen, Attribute, Beziehungen oder Versionen prüfen muss.
Was ein Mensch sehen sollte
Der Autorenablauf sollte Ziel, Material, Quellengrenzen, Validierungsergebnis, echte Vorschau und die ausstehende Freigabeaktion zeigen. Rohes OWX ist eine Audit-Oberfläche, nicht die standardmäßige Leseransicht. Der Besitzer kann Quellpaket und exakten Digest prüfen, wenn Herkunft oder Debugging wichtig sind.
Neu bei OWL Compose?
Starte mit deinem Agent.
Lerne zuerst den Produktablauf kennen. Komm nur zurück, wenn der Agent oder ein Auditor den zugrunde liegenden Vertrag benötigt.