Choose XML tools by the work they perform: editing, schema validation, querying, transformation, and mapping. Evaluate candidates with the same small project and expected failures. An editor becomes more useful when its checks also run repeatably outside it.
Write a capability brief
| Task | Required detail | Trial exercise |
|---|---|---|
| Edit | Namespace-aware completion and diagnostics | Rename an element and inspect the error. |
| Validate | Schema language and version | Validate good and bad fixtures locally. |
| Query | XPath version and namespace context | Find and count two namespaced items. |
| Transform | XSLT version and processor | Produce the expected HTML. |
| Map | Repetition, missing values, type conversion | Map records with an absent optional field. |
“Supports XML” leaves several questions unanswered. Record processor versions, licensing for automated use, offline behavior, platform support, and how settings travel to another machine. Keep price and availability checks separate from the durable workflow. Evaluate a candidate against your contract before committing the team to it.
Run one project from input to output
Download the XML practice pack, extract it, and open the folder in your editor. It contains a fictional two-item catalog, XSD 1.0 schema, XSLT 1.0 stylesheets, and scripts. With Python 3.10 or later, run:
python -m pip install lxml
python validate_catalog.py
python parse_catalog.py
python publish_catalog.py
python selftest.pyValidation reports success, parsing prints two item lines, and publishing creates catalog.html and catalog.fo. Open the HTML and confirm the names and quantities. A successful process exit and a useful output are separate observations.
Bind c to urn:yenra:catalog in the query environment. count(/c:catalog/c:item) should yield 2. Try a different namespace URI and investigate the empty selection. This tests whether the tool exposes query context clearly.
Match the language to the processor
lxml’s validation guide describes supported validation mechanisms. Its XPath and XSLT guide describes XPath 1.0 and XSLT 1.0 functionality. The exercise deliberately uses those versions.
For a project requiring XSLT 3.0, evaluate an implementation supporting the specific features and edition you need. The W3C XSLT 3.0 specification defines the language; it does not establish what every tool implements. Keep an example of each required feature in the trial project.
Version schemas and stylesheets with the source. Resolve approved includes locally and record the dependency versions that produced each release. A colleague should reproduce the build from documented settings without rediscovering editor preferences.
Diagnose differences between tools
First confirm both tools read the same bytes, encoding, schema, and stylesheet. Then inspect namespace bindings, base URIs, and relative paths. Compare language versions and parser options. Read the first meaningful error and reduce the input to a minimal failing case.
Separate syntax, schema, and application-rule failures. Quiet recovery or dropped records can change output while making a demonstration look successful. When recovery is deliberately supported, retain diagnostics and reconcile accepted, rejected, and deferred records.
Make one documented command the team’s build entry point. Run it in automated checks, save diagnostics on failure, and review generated changes alongside source changes. Rerun positive and negative fixtures after an upgrade: new diagnostics or defaults may change the outcome even when the document is unchanged.