Human users should not be forced to edit XML documents. Sometimes, they may want to read it. The presentation persists some arguments I stated about this topic again and again in the past. Discussions and opinions are more than welcome.

1. Humans should not
write XML.
Sometimes, they may need to read it.
Dr. Peter Tröger
Operating Systems Group
TU Chemnitz, Germany
April 2016

2. Data vs. Document
• Model-View-Controller
• Application data lives in the model.
• Users deal with the view.
• Controller tampers with the model data.
• What are (XML) documents then?

3. Documents
• Persistent version of application state as file.
• Example: All software with text editing capabilities.
• Document files may be passed around by humans.
• Users can live without document concept.
• When the application state persists anyway.
• Example: Most smartphone apps. Cloud apps.

4. XML is for documents
• Document markup language
• Must be extensible, which makes it complicated.
• Must be universal, which makes it complicated.
• Must be portable, which makes it less flexible.
• Must be software-processable.
• Should (not must) be human-readable.

5. https://www.w3.org/TR/2008/REC-xml-20081126/
XML must be software-
processable.
XML should be human-
readable.
Making XML less
complicated is
a non-goal.

6. Humans vs. XML
• XML is supposed to be human-readable.
• Application views are filters for application data.
• Reading the document gives you the core
version of application data.
• If your application is perfect, you don’t need that.
• XML is not supposed to be human-writable.

7. Example:
XML for Interface Descriptions
• WSDL, AUTOSAR XML, ...
• On first look, it sounds ok.
• Interfaces descriptions are documents.
• They are (hopefully) processed offline.
• May be passed around between developers.
• Interesting question is the origin of the document.

8. Example:
XML for Interface Descriptions
• Option 1: Brain -> DSL -> XML Interface Description
• Domain engineer has natural language / tool.
• XML is just the document format.
• Option 2: Brain -> Code -> XML Interface Description
• Forget it. Learn from SOAP-RPC history.
• Option 3: Brain -> XML Interface Description.
• Humans should not write XML.

9. Example:
XML for Messaging
• The logic:
• Software-to-software messages are documents.
• XML is for documents. Let’s formulate messages in XML.
• Even worse:
• Implementing RPC demands messaging.
• Messages can be formulated in XML.
• Let’s formulate RPC requests in XML. On the wire.

10. Example:
XML for Messaging
• What is wrong with that argumentation?
• XML is a document format.
• Document formats are not intended for efficiency.
• But messaging data formats should be efficient.
• Document formats are for offline use.
• But messaging is an online problem.
• XML is the wrong tool for the messaging job.

11. And JSON?
• The JSON hype refuses to die.
• Closer to developers (data) thinking.
• Automatically leads to quick engineering results.
• We get many many re-invented wheels.
• JSON-based interface descriptions.
• JSON-based messaging / RPC.
• XML and JSON solve different problems.
Documents vs. data. There is no competition.

12. Conclusion
• Everybody hates XML editing.
• Correct, never intended for that.
• Fix the XML generating application, instead.
• Rules of thumb
• XML is an offline format. Don’t use it online.
• Document exchange and data exchange are not the same.
• Humans should never be forced to write (or click) XML.