Exchange Formats

Overview

• Exchange formats enable communication between systems on the syntax level
• Exchange formats describe the structure of the data

Common exchange formats

• CSV (1970s) — simple tabular data, still common in imports/exports
• EDIFACT (1980s) — standardized business documents, ISO 9735 standard
• XML (1990s) — flexible, hierarchical, machine- and human-readable, W3C standard
• JSON (early 2000s) — lightweight alternative for Wbe applications, de facto standard for Web APIs

➜ EDIFACT, XML, and JSON are discussed in detail.

EDIFACT — Syntax

|_Service String Advice              UNA  Optional
|____Interchange Header              UNB  Mandatory
     |___Functional Group Header     UNG  Conditional
         |___Message Header          UNH  Mandatory
             |__ User Data Segments       As required
         |__ Message Trailer         UNT  Mandatory
     |__ Functional Group Trailer    UNE  Conditional
|___ Interchange Trailer             UNZ  Mandatory

EDIFACT — Purchase Order (ORDERS)

UNA:+.? '
UNB+UNOC:3+SENDERID+RECEIVERID+240401:1200+123456789'
UNH+00000001+ORDERS:D:96A:UN'
BGM+220+PO12345+9'
DTM+137:20240401:102'
NAD+BY+123456789::16'
NAD+SU+987654321::16'
LIN+1++123456:IN'
QTY+21:5'
PRI+INV:1200.00'
UNS+S'
UNT+11+00000001'
UNZ+1+123456789'

Exercise: Analyzing an EDIFACT Message

• Analyze the EDIFACT message available here
• Answer the following questions:
  • What type of transaction does this message represent?
  • What is the document reference and when was it issued?
  • Who are the sender and receiver? What are their identification numbers?
  • What are the monetary amounts involved, including taxes?
  • What items are being invoiced, quantities and unit prices?
  • How many messages are included in this interchange?

• Start with UNH and BGM.
• Use the message type directory for further analysis.

EDIFACT

• Robust framework for structured business transactions at scale
• Widely used despite complexity: logistics, supply chain, global trade
• Understanding syntax and building blocks is essential for working with legacy systems and EDI-based industries

XML

• XML — Extensible Markup Language
  • XML 1.0 published by W3C in 1998
• Widely-used format for data representation and exchange
• Designed
  • to be machine-readable and human-readable
  • flexibility to represent complex, hierarchical data structures.
• XML has become a cornerstone of modern data interchange, particularly in enterprise systems

• Hundreds of document formats using XML syntax have been developed, including RSS, Atom, Office Open XML, OpenDocument, and SVG.
• XML also provides the base language for communication protocols such as SOAP and XMPP.

(Wikipedia)

XML

<?xml version="1.0" encoding="UTF-8"?>
<product>
  <id>12345</id>
  <name>Mountain Bike</name>
  <price currency="USD">1200.00</price>
  <stock>10</stock>
</product>

XML

<?xml version="1.0" encoding="UTF-8"?>
<product>
  <id>12345</id>
  <name>Mountain Bike</name>
  <price currency="USD">1200.00</price>
  <stock>10</stock>
</product>

Well-Formed XML

An XML document is well-formed if:

• Unicode: It contains only properly encoded Unicode characters.
• Special characters: None of the special syntax characters such as < and & appear except when performing their markup-delineation roles.
• Nesting:
  • The begin, end, and empty-element tags are correctly nested
  • none missing and none overlapping tags
• Matching tags:
  • Element tags are case-sensitive. The beginning and end tags must match exactly
  • Tag names cannot contain any of the characters !"#$%&'()\*:;<=>?@[\]^{|}~ nor a space character
  • Tag names cannot start with -, ., , , or a numeric digit
• Single root element: There is a single “root” element that contains all the other elements

Namespaces in XML

<bookstore xmlns:bk="http://example.org/books">
  <bk:book>
    <bk:title>Learning XML</bk:title>
    <bk:author>John Doe</bk:author>
    <bk:price>39.95</bk:price>
  </bk:book>
</bookstore>

• Avoid naming conflicts when combining data from different sources or standards
• Declared via xmlns attribute (typically in the root element)
• Prefix (e.g. bk) qualifies elements as belonging to the namespace

XML Schema Languages

• One of the oldest schema languages for XML
• Defines elements, attributes, order, simple types

<!DOCTYPE product [
  <!ELEMENT product (id, name, description, price, stock)>
  <!ELEMENT id (#PCDATA)>
  <!ELEMENT name (#PCDATA)>
  <!ELEMENT description (#PCDATA)>
  <!ELEMENT price (#PCDATA)>
  <!ATTLIST price currency CDATA #REQUIRED>
  <!ELEMENT stock (#PCDATA)>
]>

Exercise: Analyzing an XML Document

Given the customer XML document and the corresponding XSD (cf. lecture notes):

1. Does the XML document conform to the schema? Why or why not? If not, what changes would be needed?
2. How would validation fail if the country field had more than 2 characters?
3. What happens if email is missing, given that it’s a mandatory field?

JSON

• Lightweight, text-based format for structured data
• Originally designed for JavaScript — now de facto standard for Web APIs
• Libraries available in most modern programming languages

{
  "product": {
    "id": 12345,
    "name": "Mountain Bike",
    "price": 1200.0,
    "currency": "USD",
    "stock": 10
  }
}

JSON Schema

{
  "$schema": "http://json-schema.org/draft/2020-12/schema#",
  "title": "Product",
  "type": "object",
  "properties": {
    "id": { "type": "number" },
    "name": { "type": "string" },
    "price": { "type": "number", "minimum": 0 },
    "currency": { "type": "string" },
    "inStock": { "type": "boolean" },
    "discount": { "type": ["number", "null"] }
  },
  "required": ["id", "name", "price", "currency"]
}

Exercise: Validating JSON Data

Given the product JSON data and the JSON schema:

{
  "$schema": "http://json-schema.org/draft/2020-12/schema#",
  "title": "Product",
  "type": "object",
  "properties": {
    "id": { "type": "number" },
    "name": { "type": "string" },
    "price": { "type": "number", "minimum": 0 },
    "currency": { "type": "string" },
    "inStock": { "type": "boolean" },
    "discount": { "type": ["number", "null"] }
  },
  "required": ["id", "name", "price", "currency"]
}

{
  "id": 12345,
  "name": "Mountain Bike",
  "price": 1200.0,
  "currency": "USD",
  "inStock": true
}

1. Does the data conform to the schema?
2. What happens if price is set to -100?
3. What if the currency field is missing?
4. How does validation behave if an extra field (e.g. description) is added?

Comparison: JSON vs. XML

JSON: lightweight and easy for web services and APIs. XML: sophisticated options for complex data with schema validation.