Standards
A team shares invoice data with an accounting application. Both applications need to agree on the values they exchange and the requirements those values must meet. Inventing a private convention makes each new integration learn decisions that other projects have already made. Established standards let the team reuse those agreements and concentrate on the meaning specific to its invoices.
Different teams are likely to choose different languages and technology stacks. The team investigating disputes may build a web application, while the accounting team uses tools suited to financial reporting. Sharing invoice data should not require either team to adopt the other's stack. Standards let them agree on the data while choosing their tools independently.
JSON provides a common vocabulary for structured data that is independent of the application's language. An invoice can be exchanged as a document without requiring the recipient to adopt the sender's classes. Existing tools can read that document. The integration still needs agreement about what its fields mean, such as whether an amount includes tax.
JSON Schema gives those applications a shared language for expressing structural requirements. Both applications can use the same schema to state the requirements for payment. That makes the agreement available to people and tools that already understand the standard. The business still decides which requirements apply, as described in Schemas.
DUST
People also need to read and review the data. An investigation may involve examining an invoice beside the query that selected it, or reviewing a change to the payment requirements. A format suitable for exchanging documents between programs can be cumbersome for that work. DUST provides a notation intended for human reading and authoring while using the same value model as JSON.
A reviewer may need a note explaining why a payment requirement changed. Comments let that explanation accompany the document being reviewed. Its values still need to agree with the JSON document used by the accounting application. People should be able to choose a readable notation without maintaining a separate version of the invoice or its rules.
Extensions
A standard may leave a useful distinction unexpressed, such as the difference between a reference and a quantity described in Components. An extension adds something that a team must learn. A new format or type should address a recurring need beyond one product to justify that cost. For example, people should be able to use DUST to review documents even when no Stardust database is involved.