Intro to XML and XSD

Understanding XML is a fundamental part of using web services. XML stands for eXtensible Markup Language. Some consider it the next (or this) generation’s method for defining data so it does not depend on a specific operating system or programming language. The following RPG data structure can help demonstrate the different strategy XML uses to store data:


D PostAdr    DS
D  residential                    N
D  title                         5A
D  name                         15A
D  street                       15A
D  cty                          10A
D  state                         2A
D  zip                           5A
D  phone                        12A   Dim(2)

If it were filled with data it would look similar to this in memory:

If an XML formatted document stored that same data, a beginning and an ending tag would delimit the actual variable data. Look at the following XML and note the relationships to the above data structure:


<PostAdr residential="true">
  <name title="Mr.">Sample Resident</name>
  <street>999 Totally A Real Street</street>
  <city>Cityville</city>
  <state>OH</state>
  <zip>12345</zip>
  <phone>123-456-7890</phone>
  <phone>987-654-3210</phone>
</PostAdr>

With the tags as markers, readers can identify each piece of data with its start and stop points. Yes, the tags consume a large amount of space to describe each piece of data. XML does require a great deal of hard drive space and memory compared to more traditional data storage formats. However, this space usage has become the norm as the popularity of the XML standard has grown.

Note that the XML looks “pretty” in the above formatting. It is frequently stored in memory or files without carriage returns or whitespace, like in the following example:

<PostAdr residential="true"><name title="Mr.">Sample Resident</name><street>999 Totally A Real Street</street>...

A beginning tag (i.e. <zip>) and an ending tag (i.e. </zip>) delimits each piece of data. The “</” denotes the end tag. These tags, as they are often called, would be more appropriately called “elements”, but the names are interchangeable. Each element can have child elements, attributes, and/or textual content.

The <PostAdr> has child elements <name>, <street>, <cty>, <state>, <zip>, and <phone> (x2). It also has an attribute named residential. An attribute further defines an element. (For more information on when to use attributes vs. elements please see the section titled “When to Use Attributes vs. Elements”.)

Also note that <PostAdr> encompasses the elements <name>, <street>, <cty>, <state>, <zip>, and <phone> (x2). That shows what eXtensible means. Theoretically one could put as many elements as needed or wanted within the <PostAdr> element. Someone could even embed additional elements within one of <PostAdr>’s child elements. For example, a further-defined <name> element might appear as follows:


<PostAdr residential="true">
  <name title="Mr.">
    <first>Sample</first>
    <last>Resident</last>
  </name>
  <street>999 Totally A Real Street</street>
  <city>Cityville</city>
  <state>OH</state>
  <zip>12345</zip>
  <phone>123-456-7890</phone>
  <phone>987-654-3210</phone>
</PostAdr>

The <name> element now has two new child elements—<first> and <last>. The XML “eXtended” to make the definition of the data more detailed.

Some might wonder “What happens to programs that are expecting the first version of <PostAdr> with the simple definition of <name>?” Their apprehension is justified. Those programs would no longer look the right place for the name element within the postal address element. XML is not magic. If you trade XML documents with another program (or business partner), both sides of the transaction must agree on the format. An XML Schema (XSD) is one way to describe an agreed-upon XML format.

The PostAdr RPG data structure has definitions for each of its sub-fields. Each sub-field has a data type and a length. Without an agreement concerning data types, an XML file passed back and forth could produce runtime errors when programs try to access (or parse) the XML. To meet this need, the definers of the XML specifications created what they called XSDs or XML Schema Definitions. An XSD defines the structure of a document and what type of data can appear in each of the elements. Take the following XML Schema Definition which defines the <PostAdr> element.


<schema>
<element name="PostAdr">
  <complexType>
    <sequence>
      <element name="name">
        <complexType>
          <sequence>
            <element name="first" type="string"></element>
            <element name="last" type="string"></element>
          </sequence>
          <attribute name="title" type="string" />
        </complexType>
      </element>
      <element name="street" type="string"></element>
      <element name="cty" type="string"></element>
      <element name="state" type="string"></element>
      <element name="zip" type="string"></element>
      <element name="phone" type="string" minOccurs="1" maxOccurs="2"></element>
    </sequence>
    <attribute name="residential" type="boolean" />
  </complexType>
</element>
</schema>

Oddly, this might look like an XML file to you. You are not confused. XSDs use XML to define themselves. The first tag is the tag. It merely declares what type of document we are in. Next is <element name="PostAdr">. That essentially declares the name of the element being described. Within the <element… tag there is a <complexType> tag which states PostAdr either has attributes or children elements, or both. The <name> element needs to be defined within the <PostAdr> tag. The <sequence> tag specifies that realtionship. The contents of the <sequence> tag should contain only a sequence of child element definitions. The innermost children will be simple datatypes defined by the type="string" attribute (or other primitive data type). The value of the data type attribute could specify a variety of types ranging from numerical to dates, timestamps, Booleans, and so forth.

Next note the definition of the phone element. It states that it can contain a string and must have at least one occurrence of the <phone> element included in the XML document at transaction time. It also states that there can be a total of two <phone> elements sent (i.e. maxOccurs=”2”)

Finally note the definition of an element’s attribute (i.e. the residential attribute of element PostAdr) located within the PostAdr’s <complexType> tag. Using the <attribute> tag defines the name and type - residential and boolean respectively.

The nested aspect of an XML Schema Definition is similar to the relationships between commonly used IBM i Physical Files. Consider an order application that maintains data taken over the phone. That application would likely rely on a header (or parent) type file describing when the order was taken, the customer number, when the order will ship, and so forth. It could also use a detail (or child) file holding multiple line items in a single order. Its records could specify things like item ordered, quantity, unit price, extended price, discounts, and the like.

That is a high-level overview of XML and XSD from an RPG programmer’s perspective.