Technical references built around working examples.

Editorial principles

Technical claims should be traceable to a specification, reproducible example or clearly described test. A conversion tool should identify information it cannot represent. A validator should state which standard and version it implements. Tool limitations belong next to the result, not in hidden documentation.

xFront distinguishes syntax, validation, compatibility and semantics. A document can be well formed without being valid, valid without satisfying a business policy and structurally compatible without preserving the meaning a consumer relies on. References name the layer making a claim so readers can decide what additional evidence their system requires.

How references are maintained

Durable subject URLs are treated as part of the technical product. Established XML Schema, REST, XSLT, Schematron, Microformats, RDF, OWL and data-format routes are retained when the site changes. A legacy resource that has a complete modern equivalent is redirected to the closest subject page; strong topic pages are rebuilt as direct references.

Examples are deliberately small. They isolate one decision, include the surrounding namespace or version information and avoid implying that a short fragment is a complete production policy. Where browser APIs implement only a subset of a standard, the page states that boundary and points to the kind of processor required for full validation.

Browser privacy

The workbenches currently published on xFront process input inside the browser tab. They do not send pasted schemas or documents to an xFront server. This behavior is stated on each applicable tool page so that future tools with different requirements can be described accurately.

Browser-local processing is a useful privacy property, but it is not a substitute for the user’s own data-handling policy. A pasted contract can remain in browser history, extensions, screenshots or the device’s memory. Users working with sensitive material should use minimized examples and a controlled device even when no network upload occurs.

Corrections and scope

The editorial scope is schema and data-contract engineering: XML, XSD, Schematron, XSLT, XProc, JSON Schema, OpenAPI, semantic-web formats and closely related formal-language topics. Pages are written by the xFront Editorial team and updated when an example, technical statement or tool behavior changes.

The methodology page describes testing and source selection. Material behavioral changes are listed in the changelog. A correction should identify the affected URL, the claim or example in question and a reproducible counterexample where possible.

What a maintained reference promises

A maintained reference preserves its subject and URL while improving the explanation around it. It does not claim authorship of every historical resource associated with that path, and it does not silently turn a cited technical download into unrelated content. Recoverable original files remain available under their exact paths; unavailable material points to the nearest complete subject reference.

Maintenance also means stating uncertainty. Standards support differs among processors, and compatibility depends on actual consumers. Where a browser tool uses a heuristic, the result is labeled as analysis rather than conformance. Readers should be able to tell which conclusion follows from a specification, which follows from a test and which still requires a decision in their own environment.

xFront does not sell validation, certification or placement in these references. There is no commercial ranking of processors or standards. The project is optimized for durable technical usefulness: clear decisions, runnable examples, stable citations and tools that remain accessible without an account.