|
| 1 | +--- |
| 2 | +applyTo: "**" |
| 3 | +--- |
| 4 | + |
| 5 | +# Domain Knowledge |
| 6 | + |
| 7 | +This site documents multiple libraries in the `json-everything` ecosystem plus generated API reference and release notes. |
| 8 | + |
| 9 | +## Documentation Taxonomy |
| 10 | + |
| 11 | +- `_docs/schema`, `_docs/pointer`, `_docs/path`, `_docs/patch`, `_docs/logic`, `_docs/json-e`, `_docs/yaml`, etc. are product/topic sections. |
| 12 | +- `_docs/release-notes` contains versioned change logs by library. These are edited in the main `json-everything` repository and copied here. Do not edit release note pages in this repo. |
| 13 | +- `_docs/api` is API reference content, generally generated. Do not edit generated API member pages in this repo. |
| 14 | + |
| 15 | +## Terminology and Naming |
| 16 | + |
| 17 | +- Prefer official library naming as used in existing docs (for example `JsonSchema.Net`, `JsonLogic`, `JsonE.Net`). |
| 18 | +- Distinguish clearly between: |
| 19 | + - JSON Schema specification behavior. |
| 20 | + - `json-everything` implementation behavior. |
| 21 | +- For behavior claims, prefer explicit wording and examples over marketing language. |
| 22 | + |
| 23 | +## Cross-Linking and Versions |
| 24 | + |
| 25 | +- Prefer relative links to pages within this site. |
| 26 | +- Use stable external links to specs and official project resources where helpful. |
| 27 | +- When documenting version-specific behavior, name the library/package and version explicitly. |
| 28 | + |
| 29 | +## Voice and Audience |
| 30 | + |
| 31 | +- Audience is developers using .NET libraries and adjacent JSON tooling. |
| 32 | +- Keep voice technical, direct, and pragmatic. |
| 33 | +- Aim for friendly but not personal: approachable and human, but not informal or chatty. |
| 34 | +- Prefer active voice and concrete behavior statements over abstract wording. |
| 35 | +- Include concise examples when they reduce ambiguity. |
| 36 | +- Distinguish style by content type: |
| 37 | + - Tutorial/basics pages: explanatory with practical examples. |
| 38 | + - Warnings and gotchas: explicit about risk and impact. |
| 39 | +- Prefer precision over promotion: |
| 40 | + - State defaults, constraints, edge cases, and failure behavior. |
| 41 | + - Avoid marketing language and unsupported claims. |
0 commit comments