Skip to main content
Validate the complete contract against its XSD files before submitting it. Use an XML editor or validator that can load multiple schemas and resolve imports by namespace.

​
1. Save the schema dependencies

Download the eight XSD files in the contract authoring schema set into one local directory. Use the filenames listed in the catalog. The schema manifest records each exact namespace, source URL, dependency, and SHA-256 checksum. Compare downloaded files with these checksums to confirm you have the documented revision. For a LegalLab example with extra namespaces, also save its listed additional schemas. A custom payload requires its own XSD; follow custom schema authoring.

​
2. Associate namespaces with local files

In your validator’s schema-set or XML-catalog settings, associate each namespace with the corresponding local XSD from the catalog. Load all dependencies before validating the contract. For example, associate urn:nf:iot:leg:sc:1.0 with SmartContracts.xsd. That schema imports identity, key, and XML-attribute definitions; the key schema also imports peer-address types. Some imports omit a file location, so opening only SmartContracts.xsd is insufficient. Use the exact namespace strings. A namespace identifies the vocabulary; the downloaded file is its local schema location. Keep these associations in your validator configuration without changing the contract’s namespaces. Disable DTD processing and external network resolution for an offline check. Configure the validator to report elements with missing schemas, including machine-readable content inside the contract.

​
3. Validate the complete XML

Save the complete document as MyContract.xml, select the loaded schema set, and run XSD validation. Check the document root, required attributes, element ordering, and value types. Expected result: the schema set compiles and the document has no validation errors. A message that XML is merely well-formed does not establish XSD validity. As a check that your schema configuration is active, temporarily remove a required attribute such as startState from a state-machine definition. Validation should fail. Restore the original document before continuing.

​
4. Check machine references

For a contract containing a state machine, check references separately from the XSD result:
  • startState and transition newState values must name defined states in the same machine.
  • Each actionRef must name a defined action in that machine.
  • Event references must match their declared event identifiers.
Use the state-machine reference to inspect the relevant elements. A validator may need additional checks for these relationships beyond XSD validation.

​
Diagnose validation failures

​
Continue with the Agent API

XML validation checks structure. It does not evaluate Script, verify signatures, approve templates, or execute a token’s lifecycle. Submit the validated file through the contract authoring workflow, then observe approval and execution separately. For a custom vocabulary, confirm the provider can resolve its schema before submission. Your local namespace-to-file associations do not configure the provider’s schema resolver.

​
Original references