This page is a collection of notes on how to create DFDL schemas in a way that really helps keep you out of various XSD snarls and complexities and ensures the schemas can be used with JSON as well as XML.
As of this writing (2023-02-13) many of the DFDL Schemas we have created do not follow all these conventions perfectly. We have learned as we have gone along.
...
The "Hard" variation is because we place strongly minimize the use of global elements, namespaces, and some other XSD constructs.
...
- This makes schemas more flexible for reuse because it takes no position on element names that the schema user can't avoid if they so choose.
- This makes the schema JSON compatible.
- When the only global elements are defined in a no-namespace schema, it eliminates any need for elements to carry namespace prefixes or namespace prefix definitions. This is considered a cyber-security advantage since namespace prefixes and namespace prefix definitions could be used as a covert channel without making the document invalid.
...
Hence, define an element in your schema to hold the version information. Don't append a version number to a namespace URI.
(Since JSON has no namespaces, you can't use namespaces to carry version information if you want to use JSON.)
Express DFDL Properties on the Simple Types, not the Elements
...
DFDL is for describing data that has no tags or specific syntax that the schema language can depend upon. So it provides only a subset of XSD features, and best practice is to avoid things that aren't typical in structured data systems.
JSON also has no notion of child elements with the same name, so avoiding this enables a DFDL schema to be JSON compatible.
Avoid Anonymous Choices
...