Schema tool methodology, tests and limitations.

Levels of checking

The first xFront workbenches focus on syntax and structural inspection. Findings are useful for review and learning, but they do not replace a conforming processor in CI.

Reproducible examples

Every technical claim should be testable with the smallest document that preserves the relevant structure, namespaces and values. A useful fixture set contains an ordinary valid case, a boundary case and an intentionally invalid or unsupported case. Expected results identify the kind of finding rather than relying on one processor’s exact sentence.

Schema, instance, processor version and configuration belong in the same test record. Defaults such as JSON Schema dialect, XPath binding, XSD version or selected Schematron phase can change a result without changing the input document. A report that omits those inputs cannot be reproduced reliably.

Heuristics and compatibility

The XSD Pattern Analyzer recognizes declaration shapes; it does not prove that a schema follows one pure design pattern. Schema Diff identifies selected structural changes; it does not know every consumer’s tolerance, generated binding or semantic dependency. OpenAPI-to-MCP Readiness checks whether operations expose enough machine-readable shape for review; it does not authorize autonomous use.

Compatibility is always evaluated against a producer and consumer policy. Adding an optional field may remain valid for a grammar while breaking a strict parser. Removing a numeric bound may broaden accepted instances while violating a downstream safety assumption. xFront therefore labels risk and directs users to run representative old and new consumers.

Security

XML processed in the browser uses the browser DOM parser. The published tools do not fetch external entities, schema imports or references. Remote resolution requires explicit network and trust policies and is therefore outside the current tool scope.

Browser-local execution means pasted text is not submitted to an xFront application server by these tools. It does not control browser extensions, device logging, screenshots or local history. Sensitive contracts should be minimized before inspection and handled on a device governed by the user’s own security policy.

Corrections and releases

A correction is evaluated against the specification, a reproducible example and actual tool output. Behavioral changes are recorded in the changelog. Stable subject URLs and legacy paths are tested during builds so a content improvement does not silently remove a cited technical resource.

Output design

A useful result identifies the input kind, the check performed and the boundary of the conclusion. Errors should point to a location or declaration where possible; warnings should explain the risk without presenting a heuristic as proof. Downloadable or copied reports must retain enough context to be understood after the browser tab is closed.

xFront tools favor deterministic output: the same text and tool version should produce the same result. Findings are ordered predictably, examples are embedded with the tool and no current workbench depends on an external model or network service. This makes results suitable for issue reports and design reviews even when a full validator is still required for release approval.

Accessibility is part of result design. Status is communicated with text rather than color alone, controls have explicit labels and keyboard use remains available at narrow viewports. Automated browser checks cover the main successful and failing interaction for each workbench.