Chapter 10 introduced a validation discipline built on two command-line tools: xmllint for schema validation and a Python script with lxml.isoschematron for business rules. Those tools are free, widely installed, and well-suited to production pipelines where every step needs to be scripted, auditable, and deterministic. They are, however, not well-suited to the other half of FundsXML work: exploring a schema interactively, debugging a broken delivery by eye, generating sample files for testing, transforming FundsXML into fact-sheet HTML, or integrating FundsXML validation into the editor where a developer or fund-operations analyst already spends their day.
This chapter surveys the tools that fill those interactive and developer-oriented gaps. It treats FreeXmlToolkit in detail as the primary desktop workstation for FundsXML work, then covers the smaller and more specialised tools around it (the Online Schema Viewer, the CSV Converter, the FundsXML Generator) and the integration paths into three mainstream IDEs (IntelliJ IDEA, Visual Studio Code, Eclipse). The chapter is deliberately pragmatic: it tells the reader what each tool is for, when to reach for it, and what its typical workflows look like, rather than providing a feature-by-feature reference manual. The tools themselves evolve faster than any book can track; the reference documentation at each tool's website is the authoritative source for the latest features.
One honesty note on the chapter's approach. Unlike Chapter 10, where every command and every error message in the text was produced by running real software on real files, the descriptions in this chapter are grounded in the tools' published documentation and in a reading of their source code where available, but the specific menu paths, button labels, and UI behaviours are as of a point in time and may shift with newer releases. Readers who want to follow along by hand should download the current version of whichever tool they plan to use and cross-check against its own in-application help. Appendix E lists the current official download URLs.
By the end of this chapter, you should be able to:
Before we look at any single tool, a short map of the landscape is useful, because the tools overlap in ways that the TOC-style listing does not make obvious. FundsXML work falls into a handful of distinct workflows, and most of the tools in the ecosystem serve one or more of them.
Workflow 1 — Reading and exploring a FundsXML file. The user has received a delivery and wants to look at it: browse its structure, verify that particular fields are populated, check whether the schema validation passes, and maybe run a few XPath queries. The primary tool is a FundsXML-aware XML editor, which for most readers means FreeXmlToolkit (for desktop use) or one of the IDE integrations (for readers who already live in IntelliJ, VS Code, or Eclipse).
Workflow 2 — Exploring the schema itself. The user wants to understand what a particular element means, what its allowed values are, and how it fits into the larger schema hierarchy. For this, the Online Schema Viewer is the quickest entry point — it runs in a browser, requires no installation, and presents the FundsXML schema as an explorable, hyperlinked structure. FreeXmlToolkit also offers schema browsing and can generate standalone HTML documentation from an XSD.
Workflow 3 — Generating test data. A consumer developer needs sample FundsXML files to test its ingestion pipeline. Hand-writing them is tedious; the FundsXML Generator (and FreeXmlToolkit's built-in sample-data generator) produces schema-valid documents with plausible values, ready to feed into a test suite.
Workflow 4 — Converting between FundsXML and other formats. A fund-operations analyst maintains portfolio data in Excel and needs to emit FundsXML; a data-quality analyst wants to pull FundsXML data into a spreadsheet for review. The FundsXML CSV Converter (and the spreadsheet conversion tools inside FreeXmlToolkit) fills this role.
Workflow 5 — Validating and signing. Schema validation, business-rule validation, and digital signatures are all available in command-line form (Chapter 10) and in GUI form (inside FreeXmlToolkit). A developer choosing between them will typically use the command-line tools for automated pipelines and the GUI tools for interactive debugging.
Table 11.1 — Tools and workflows
| Workflow | Primary tool | Alternatives / overlap |
|---|---|---|
| Reading and exploring | FreeXmlToolkit | IDE plugins, xmllint |
| Schema browsing | Online Schema Viewer | FreeXmlToolkit XSD module |
| Test data generation | FundsXML Generator | FreeXmlToolkit sample-data generator |
| CSV/Excel conversion | FundsXML CSV Converter | FreeXmlToolkit spreadsheet converter |
| Validation | xmllint + Schematron (Chapter 10) | FreeXmlToolkit validation module |
| Digital signatures | FreeXmlToolkit signature module | openssl / xmlsec1 |
An important observation from Table 11.1: FreeXmlToolkit appears as an alternative in almost every row. This is not a coincidence — it is a deliberately all-in-one desktop workstation that covers most FundsXML workflows in a single installable application. Readers who want a single tool rather than a collection of them will find FreeXmlToolkit the natural home; readers who prefer specialised CLI tools, or who need a specific conversion that FreeXmlToolkit does not cover, will reach for the smaller dedicated tools alongside it.
The chapter treats FreeXmlToolkit first because of its breadth, then covers the specialised tools in the order of the TOC.
FreeXmlToolkit is an open-source desktop application, built on Java 25 and JavaFX, released under the Apache 2.0 licence. It is cross-platform (Windows, macOS, Linux), distributed both as pre-built installers and as a buildable source tree on GitHub, and authored and maintained as a community project around the FundsXML standard. Despite its general-XML naming, the toolkit has been shaped over many years of FundsXML work and contains features — a schema-aware sample-data generator, a Schematron panel wired into the XML editor, a spreadsheet converter — that are specifically useful to fund-industry users even though they also apply to any XML work.
This section covers the toolkit in five subsections: what it is structurally (11.3.1), how to install and start it (11.3.2), the main editor tabs a new user encounters (11.3.3), the workflows that matter most for FundsXML (11.3.4), and where the toolkit complements rather than replaces the command-line tools from Chapter 10 (11.3.5).
FreeXmlToolkit is organised around a set of tabs in a single main window. Each tab is dedicated to one of the application's modules; switching between tabs changes the primary view without losing the files the user has opened in other tabs. The principal tabs, in roughly the order a new user encounters them, are:
Not every user needs every tab. A fund-operations analyst who primarily wants to read deliveries spends most of their time in the XML Editor; a schema maintainer spends most of their time in the XSD tab; a producer pipeline developer moves between the Schematron tab and the Settings tab. The tabs are designed to be usable independently, so there is no requirement to learn every module before becoming productive in any one of them.
Two installation paths are supported. The pre-built release is the simpler one: the releases page on GitHub (https://github.com/karlkauc/FreeXmlToolkit/releases) provides installers for Windows, macOS, and Linux, each packaged as a zip or OS-native installer. On Windows, the installer does not require administrator rights; on macOS, the .app bundle is drag-dropped into /Applications; on Linux, the binary is launched from the extracted directory.
The build-from-source path is for developers who want the latest unreleased features or who want to modify the toolkit:
git clone https://github.com/karlkauc/FreeXmlToolkit.git
cd FreeXmlToolkit
./gradlew run
Gradle downloads Java 25, JavaFX 24, and all dependencies into its local cache and builds and runs the application. The first build is slow (typically a few minutes); subsequent builds are incremental and fast.
The system requirements are modest. The toolkit runs comfortably on any machine with 4 GB of memory and a modern desktop OS, but a machine with 8 GB is more comfortable if the user plans to keep several large FundsXML files open simultaneously.
On first run, the application opens to its Welcome tab. Opening a FundsXML file for the first time is as simple as dragging the file into the main window or using the File menu. The application detects the file's format automatically — XML, XSD, XSLT, or Schematron — and routes it to the appropriate editor tab.
The XML Editor is the tab most readers will spend most of their time in, and it deserves a slightly more detailed walkthrough.
A newly opened FundsXML document appears in the main text pane with syntax highlighting: element names, attribute names, attribute values, text content, and XML comments are each coloured distinctly, so that the user's eye can immediately parse the hierarchical structure without reading word by word. The right-hand side of the window shows a collapsible tree view that presents the same document as an expandable hierarchy — clicking a node in the tree view scrolls the text pane to the corresponding line, and editing the text pane updates the tree view as the user types.
Several features that distinguish the editor from a generic text editor matter for FundsXML work:
xsi:noNamespaceSchemaLocation or xsi:schemaLocation), typing inside an element offers autocomplete for the valid child elements at the cursor position. This is particularly valuable inside deeply nested blocks like RegulatoryReportings/EMT where the field list is long and the names are easy to mistype.xmllint would produce (Chapter 10), but surfaced inline without the user having to run a separate command.Several typical FundsXML workflows are worth describing concretely, because they show how the toolkit's generic XML features combine into task-specific productivity.
Workflow A — Reviewing an incoming delivery. A fund operations analyst receives a FundsXML file from an administrator and wants to verify that the delivery is correct before passing it on. The steps are: open the file in the XML Editor, check the inline validation markers (any red underline is a reason to stop), navigate the tree view to ControlData to verify sender/receiver/date, navigate to Funds/Fund/FundDynamicData/TotalAssetValues to cross-check the NAVs against the administrator's emailed summary, and finally load the producer's Schematron rule set into the side panel to catch business-rule violations. The whole check takes a few minutes; without the toolkit, the same check would involve several command-line invocations and a manual comparison.
Workflow B — Generating a test file. A developer working on a consumer pipeline needs a sample FundsXML file to test against. The Schema Generator module (reachable from the XSD tab) reads the FundsXML XSD and produces a complete, schema-valid sample document with plausible values (dates within a reasonable range, strings of the right length, enumerated values picked from each enumeration). The generated file is not production data, but it exercises every structural path the consumer's parser needs to handle, and a developer can tweak the generator settings to control depth, element counts, and optional-field inclusion. This is a faster route to a test fixture than hand-writing one.
Workflow C — Building a Schematron rule set. A producer implementing the two-stage validation from Chapter 10 needs to author, test, and refine the Schematron rule file. The Schematron tab in FreeXmlToolkit combines an editor for the rules with a live run-against-the-current-XML pane: changing a rule re-runs it immediately against the loaded document, so the rule-author can iterate at the speed of typing. Once the rules are stable, the rule file is saved to disk and handed to the command-line pipeline (using the runner from Chapter 10.6.2) for production use.
Workflow D — Transforming FundsXML into a fact sheet. A distributor consumer wants to turn FundsXML data into a human-readable fact sheet. The XSLT Developer tab loads the FundsXML file on the left and an XSLT stylesheet on the right; the bottom pane shows the live-rendered output (HTML, text, or another XML format) as the user edits the stylesheet. Saxon's XSLT 2.0 and 3.0 support lets the user express sophisticated transformations — grouping positions by sector, aggregating NAVs by share class, formatting numbers with locale-aware separators — without leaving the toolkit.
FreeXmlToolkit and the xmllint + Python validation pipeline from Chapter 10 are not substitutes for each other; they are complementary tools with different audiences.
The CLI pipeline is for production use. It runs unattended, exits with clean status codes, logs to files, and is trivially embeddable in a CI system or a nightly batch job. It is also faster: validating a 20-megabyte FundsXML file with xmllint takes a fraction of a second, whereas the same validation inside a JavaFX desktop application takes noticeably longer because of the UI rendering and the richer parsing setup.
The GUI toolkit is for interactive use. It shows errors inline with the document, lets the user navigate to them with a click, and supports the iterative edit-validate-re-edit loop that debugging a broken file requires. It also covers tasks (XSLT authoring, interactive schema browsing, sample-data generation, favourite management) that a CLI pipeline is not well-suited to.
A mature team uses both: the producer's developers and QA analysts use FreeXmlToolkit for day-to-day interactive work, the CI pipeline uses the xmllint + Schematron runner for automated validation before every delivery is emitted, and the same Schematron rule file is shared between the two. A rule authored inside FreeXmlToolkit runs in production inside the CI pipeline without modification, and vice versa.
The Online Schema Viewer is a web-based application hosted by the FundsXML project that lets users browse the FundsXML XSD schema interactively without installing anything. It occupies a specific niche in the ecosystem: a developer who wants to answer "what does this element mean and what are its children?" without downloading tooling can open the viewer in a browser and have the answer within seconds.
The viewer presents the FundsXML schema as a navigable hierarchy. The entry point is usually the root element FundsXML4, and from there the user drills into any of its children — ControlData, Funds, AssetMasterData, Documents, RegulatoryReportings, and the rest — by clicking on them. Each element page shows:
xs:annotation/xs:documentation elements. For FundsXML 4.2.8, many elements carry annotations in several languages (English and German are most common), and the viewer displays whichever the user's browser locale is set to.minOccurs, maxOccurs).The viewer is most useful for three tasks.
Looking up a specific element. A developer writing a consumer is reading a FundsXML file and encounters OpenClosedEnded inside FundStaticData. Is this a free-text field? An enumeration? What are the allowed values? Opening the viewer, searching for OpenClosedEnded, and reading the page takes perhaps twenty seconds and replaces several minutes of hunting through the 39,000-line raw XSD file.
Comparing two versions of the schema. When FundsXML publishes a new minor release — 4.2.3 to 4.2.4, say — the viewer can often be pointed at either version through a version selector, and the changes between the two are listed in a changelog view. A developer upgrading a producer pipeline uses this to understand which new fields need to be populated and which deprecated fields to remove.
Exploring an unfamiliar region of the schema. A developer who has worked mostly with Funds and AssetMasterData needs to implement TPT (Chapter 8.7) and has never touched the RegulatoryReportings/TPT subtree before. The viewer's hyperlinked navigation makes it easy to follow the type hierarchy from the top-level TPT element down to the holding fields, reading documentation annotations at each step.
The viewer is accessed through a URL published at the official FundsXML site; Appendix E lists the current address. Access is typically free and requires no login.
Three limitations are worth knowing. First, the viewer reads the published schema, not any locally modified schema — developers working against a customised XSD need a local alternative. Second, the viewer is a read-only browser: it does not validate user-supplied files (for that, the user still needs xmllint or FreeXmlToolkit). Third, the viewer's update cadence lags slightly behind the XSD release cadence, so for very new minor versions the local FundsXML4.xsd file may be authoritative in cases where the two disagree.
A large population of fund-industry users maintains fund data in Excel or CSV files and needs to produce or consume FundsXML at the boundary. The FundsXML CSV Converter is the tool for that boundary. It can run in two directions: CSV to FundsXML, where rows in a spreadsheet are transformed into elements in an XML document, and FundsXML to CSV, where portions of an XML document are flattened into a table for review or editing.
The converter is available both as a standalone utility (for users who only need the conversion and do not want the full FreeXmlToolkit installation) and as a module inside FreeXmlToolkit itself (where it integrates with the rest of the toolkit's editing and validation workflows). Both versions produce equivalent results; the choice between them is a matter of preference.
The direction from CSV to XML is the more common use case. A fund operations analyst maintains a spreadsheet with columns like ISIN, Name, Currency, NumberOfShares, NAV, and NavDate, and wants to produce a FundsXML delivery from it. The converter needs two inputs:
Given these two inputs, the converter emits a FundsXML file that follows the XSD structure and can be fed into the Chapter-10 validation pipeline before being shipped.
The mapping specification is where the complexity lives. For a simple flat spreadsheet producing a simple ShareClass list, the mapping is short: one row per line, each row naming a column and its target XPath. For a realistic fund structure with share classes, portfolios, and dynamic data, the mapping is more involved, because the CSV's flat rows have to be folded into the hierarchical FundsXML structure. Producers who use the converter regularly typically maintain a library of mapping files, one per data type, reused across many conversion runs.
The reverse direction is useful for data review. A data-quality analyst who received a FundsXML delivery and wants to check the portfolio section against a reference list in Excel runs the converter in the FundsXML-to-CSV direction, selects the Portfolio/Positions/Position elements as the source, and emits a CSV with one row per position and columns for ISIN, Quantity, MarketValue, and whichever other fields the analyst needs. The CSV can then be opened in Excel, compared to the reference list, and the differences reviewed.
The converter does not round-trip perfectly. A FundsXML-to-CSV conversion typically loses information that does not fit into the flat tabular model — repeated elements with complex structure, language-tagged text fields, nested sub-elements. The tool marks these as "unmapped" in the output, so that the user is aware of the data that did not make it into the CSV.
The standalone converter and the FreeXmlToolkit grid view (§11.3.3) overlap in their FundsXML-to-CSV purpose, but their strengths are different. The grid view is an in-place editor: the user loads a FundsXML file, switches to grid mode for a particular section, edits cells, and saves — the underlying XML is updated in place. The CSV converter is a file-to-file transformation: the input is FundsXML, the output is a separate CSV, and edits to the CSV do not flow back to the XML unless the user runs the reverse conversion. Users who need to edit in place prefer the grid view; users who need a separate output file to share with an Excel user prefer the converter.
The FundsXML Generator is the tool that produces sample FundsXML files — valid documents with plausible content — for use as test fixtures, development aids, and demonstration material. A consumer developer implementing a new ingestion pipeline uses the generator to create a set of test files that exercise every code path the pipeline needs to handle; a producer developer uses it to create a fresh sample file after a schema upgrade to verify that the producer's downstream handlers still work.
The generator, like the CSV converter, exists both as a standalone tool and as a feature inside FreeXmlToolkit (where it is accessible from the XSD tab's "Generate Sample" action).
A sample FundsXML document is not the same as a real one. The generator aims for structural completeness — every optional element included at least once, every enumerated value exercised across the file, every reasonable cardinality covered — rather than for semantic completeness. The values are drawn from a library of plausible defaults: ISINs that look like ISINs (right length, right character classes), dates in a configurable range, country codes picked from a small set, text fields populated with identifiable placeholder strings, numeric fields with randomised values within sensible bounds.
Consumers of a sample file should know that the numbers do not represent a real fund and should not be taken at face value for business-logic testing. The file is a structural test vehicle: its job is to exercise the consumer's parser, not to trick it into thinking it is reading a real delivery.
A sample-file generator has several knobs that a developer typically needs to control:
maxOccurs > 1. A portfolio with a hundred positions exercises different code paths from a portfolio with two positions; both are useful for different tests.Production usage of the generator typically involves a short configuration file that sets these options, plus a script that runs the generator on every CI build to produce a fresh set of fixtures that the consumer pipeline can then run against.
The generator is useful but not a substitute for real test data. Once a producer pipeline is running, the best regression fixtures are captured snapshots of actual deliveries — anonymised if necessary — because they exercise the quirks and edge cases that a generator does not anticipate. The mature practice is to use generator output for initial development and schema-upgrade testing, and captured real data for ongoing regression testing. Chapter 13 returns to this distinction in the context of implementation projects.
Many FundsXML developers — both on the producer side and on the consumer side — spend most of their working day inside an integrated development environment rather than in a dedicated XML tool. For those developers, the most valuable integration is inside the IDE they already use, with FundsXML validation and navigation available as first-class features of the editing experience. All three major cross-platform Java and polyglot IDEs — IntelliJ IDEA, Visual Studio Code, and Eclipse — support FundsXML well through their generic XML facilities. No FundsXML-specific plugin is required in any of the three; what is required is the standard XML support plus a correctly configured schema location.
IntelliJ IDEA's bundled XML support is comprehensive and works against any XSD out of the box. Opening a FundsXML file in IntelliJ gives the user syntax highlighting, fold markers, and navigation; enabling schema validation requires telling IntelliJ where to find FundsXML4.xsd.
The simplest path is the xsi:noNamespaceSchemaLocation attribute on the root element, which IntelliJ respects. If the FundsXML file is stored in the same directory as FundsXML4.xsd (or in a directory referenced by a relative path in the attribute), IntelliJ finds the schema automatically and enables validation, autocomplete, and "go to definition" on every element. The error markers in the gutter match the xmllint errors from Chapter 10.
For projects that store the schema separately from the data, IntelliJ's Settings → Languages & Frameworks → Schemas and DTDs lets the user map a schema file to a pattern of XML files. Mapping FundsXML4.xsd to *.xml in a FundsXML-data directory enables full schema support without needing the xsi: attributes.
IntelliJ's XPath evaluator (under the Edit → Find → Find Usages / XPath Search menu) is a useful companion for exploring a FundsXML file by query. The XSLT debugger, while not FundsXML-specific, is equally useful for developing XSLT stylesheets that transform FundsXML into other formats.
Visual Studio Code does not ship with XML support by default, but the Red Hat XML extension (redhat.vscode-xml) is free, widely used, and provides a comparable level of functionality to IntelliJ's built-in support. Installing it from the VS Code marketplace takes under a minute; once installed, it detects .xml files automatically and offers schema-driven features.
Schema association works the same way as in IntelliJ: either the xsi:noNamespaceSchemaLocation attribute on the root element, or a project-level configuration in VS Code's settings that maps schemas to file patterns. The Red Hat extension reads a .settings/org.eclipse.wst.xml.core.prefs file (inherited from Eclipse WTP conventions) and also a VS Code-native configuration, so either approach works.
The extension provides continuous validation, auto-formatting, XPath evaluation, and XSLT 3.0 support through its bundled Saxon-HE. For a developer who lives in VS Code, it is the most capable path into FundsXML work, and the experience closely mirrors FreeXmlToolkit's XML Editor without requiring a separate desktop application to be running.
Eclipse has supported XSD-aware XML editing for many years through the Eclipse Web Tools Platform (WTP), which is included in every Eclipse IDE for Java EE Developers and most other Eclipse packages. The WTP XML editor is mature, well-tested, and fully schema-aware.
For FundsXML work in Eclipse, the typical configuration is to register FundsXML4.xsd in Preferences → XML → XML Catalog, which maps a public or system identifier to the local schema file. Once registered, any FundsXML file opened in the editor resolves its schema automatically and gets validation, autocomplete, and "open declaration" navigation.
Eclipse's support for XSLT and Schematron comes through additional plugins (the Eclipse Marketplace has several; the names change over time, so the current recommendation is to search the marketplace for "Schematron" and "XSLT" and pick the most recently updated result). The core XML editor is what most FundsXML developers use day to day; the specialised plugins are reached for only when a specific workflow needs them.
All three IDEs provide equivalent FundsXML functionality for the core editing tasks: syntax highlighting, schema validation, autocomplete, and navigation. The choice between them is almost always determined by the surrounding toolchain rather than by any FundsXML-specific feature. A developer whose project is Java and uses Gradle or Maven will find IntelliJ or Eclipse natural; a developer whose project is polyglot (Python, Go, Rust, JavaScript, with XML at the boundary) will find VS Code lighter-weight and faster to start. None of the three has a compelling advantage for FundsXML work specifically, and a team with developers using all three can share Schematron files, XSD files, and code without friction.
xmllint + Schematron pipeline from Chapter 10. Use the right tool for the right job.xmllint --xpath queries from the command line one at a time. It is possible but tedious; an interactive editor with tree view and XPath evaluation is dramatically faster for exploration tasks.xmllint (or whichever validator the pipeline uses) before emission, because the pipeline's validator is the authoritative one.xmllint, lxml.isoschematron) and the interactive tools from this chapter are complementary, not competitive. A mature team uses both: CLI for pipelines, GUI for interactive debugging and development.With the tooling landscape mapped, the next question is: how does a FundsXML pipeline fit into a larger system landscape? Chapter 12 treats that question. It covers typical architecture scenarios, the choice between programming languages for FundsXML work, strategies for reading and writing at scale, database and data-warehouse integration, and the scheduling and automation patterns that take a FundsXML producer from a proof-of-concept to a production pipeline.