OE1-5.3 XML & JSON

What this is and why it exists

Two systems that share no code need to exchange structured data. Both formats in this topic solve that problem, and comparing them is the point.

One is verbose and can be validated automatically. The other is compact and maps straight onto the data structures of the language reading it. That difference decided which one modern interfaces use.

The vocabulary

• Well-formed — obeying the syntax rules, so a parser can read it at all.
• Valid — additionally matching a declared description of what the document should contain.
• Root element — the single element containing everything else.
• Namespace — a qualifier keeping names from two vocabularies apart.
• Schema — a declaration of what a valid document looks like, so it can be checked.
• Parser — the code that reads the text and produces a structure.
• Serialisation — turning data in memory into text that can be sent.

The mental model

Both formats do the same job. Data lives in one program's memory in its own shapes. It has to reach another program, written by other people in another language, and mean the same thing there. Text is the neutral middle, so the data is written as text at one end and rebuilt at the other.

The verbose format is strict, and the strictness is the point. Every opening tag has a closing one, nesting cannot overlap, and there is exactly one outermost element. A parser meeting a document that breaks these rules refuses it rather than guessing. That is deliberate: guessing produces two programs that disagree about what a document says, and refusing produces an error you can fix.

Namespaces look like bureaucracy and are not. Combine two vocabularies in one document and their names collide, because both may have a title element meaning different things. A namespace qualifies each name with an identifier for the vocabulary it belongs to, so the two remain distinguishable. The problem is real, and it appears the moment documents are combined rather than written in isolation.

Schemas are the strongest argument for this format. A schema declares what a valid document contains: which elements, in what order, how many, holding what kinds of value. A document can then be checked automatically before your code touches it, and rejected with a specific message if it is wrong. In a setting where documents arrive from other organisations, that is worth a great deal.

Notice the two-level distinction that follows. Well-formed means the syntax is right and a parser can read it. Valid means it also matches the declared description. A document can be well-formed and entirely wrong for its purpose.

A browser given such a document with no styling shows its structure as a tree. That is a useful habit when debugging, because it tells you the parser could read it, which separates a syntax problem from a content problem.

Applying styling to it shows the separation of content from presentation in a second setting. That is a good check that the principle was understood rather than memorised.

The lighter format is what almost every current interface actually uses, and its advantage is directness. Its structures are objects with named members and ordered lists, which are exactly the structures most languages already have. Reading it produces usable data immediately, with no separate model to walk. It is also far shorter, because there is no closing tag repeating every name.

What it gives up is real. There is no namespace mechanism, no widely used schema attached by default, and no comments. Validation is done by your own code or by a separate tool rather than being part of the format.

So the comparison, and it is the item the topic exists for. Where documents come from outside your control, mix vocabularies, and must be validated before processing, the verbose format earns its cost. Where two systems exchange data over an interface you control, the lighter one wins. The receiving language wants objects and lists, and it is smaller and faster to parse. Knowing which situation you are in is the whole answer.

What you should now be able to explain or do

Say what problem both formats solve. Explain why strict parsing refuses rather than guesses. Explain what namespaces prevent and when the problem arises. Distinguish well-formed from valid. State the trade honestly and choose between the two for a stated situation.

Check yourself