Writing Mobile Code Essential Software Engineering for Building Mobile Applications [Electronic resources] نسخه متنی

Comparing XML to Other Text Formats

A great deal of literature exists describing XML and a full exploration of the subject is well beyond the scope of this book. Nevertheless, it is useful to present a very brief overview of how XML compares to other text-based formats. This will be done by way of example.

A Few Different Ways to Store Data as Text

Assume that our application has a need to store some user data. This user data consists of three items: an ID number, a name, and an address. Our application needs to store this data for its own use and may also want to pass the data to other applications. Three common ways to store this data as text are XML, comma-delimited values, and as values in an INI file.

Storing the data as XML

Lik139, XML stores data as text surrounded by tags that add context to the data being passed in:

<UserInfo>
<UserID> 12 </UserID>
<UserName> Bob </UserName>
<UserAddress> Someplace, Somewhere </UserName>
</UserInfo>

It is worth noting that the same data could also be stored as XML using tag attributes, for example:

<UserInfo UserID="12" UserName="Bob" UserAddress="Someplace, Somewhere"> 
</UserInfo>

If appropriate, some combination of attributes and subtags can be used. Which XML format is most appropriate depends on the specific usage of the XML. Attributes can be simpler, but tags are more flexible because they can have attributes and subtags.

Storing the Data as a Comma-Delimited File

Historically, this kind of data was often stored as comma-delimited data:

12, Bob, "SomePlace, Somewhere"

Storing the Data in an INI File

INI files have also been a popular way to store data in the past. An INI file stores data as a set of name/value pairs:

[UserInfo]
UserID=12
UserName=Bob
UserAddress=Someplace, Somewhere

Other common formats exist as well such as PropertyBags, which sit somewhere between XML and INI files in terms of structure and flexibility and were popular with Visual Basic 5 and 6 developers. What XML does above and beyond many previous formats is lend additional structure to the data. This structure allows for hierarchical data that is not order dependent. It is a bit more verbose than many other text formats, but it is much more flexible. This flexibility makes it easy to version, maintain, and pass data between different systems.

XML Data Is Hierarchical

The hierarchical nature of XML is important to understand. Think of your XML document as a tree of objects, with each object potentially having additional child objects. To show this, our XML example above can be modified to show some more hierarchy:

<UserInfo>
<UserID> 12 </UserID>"
<Name>
<FirstName>  Ivo  </FirstName>
<LastName>  Salmre </LastName>
</Name>
<Address>
<Street>10 SomeStreet</Street>
<City>Seattle</City>
<State>WA</State>
</Address>
</UserInfo>

Here we have made Name and Address subnodes of UserInfo.

Other XML Features

There is much more to XML, including standardized schema, typed data, and validation possibilities. The examples above are only the most trivial examples of XML fragments. Good documentation exists describing the intricacies of XML both in the .NET Framework documentation as well as generically on the Web. This book and its samples focus on the practicalities of using XML on mobile devices and is not in any way an exhaustive study of XML usage.

In practical usage, most XML data exchange falls somewhere in between the extremes of rigorous structure and free-form data. What level of rigor to apply to data formats is a choice left up to both the sender and the consumer of the data. A computing node generating XML may make it adhere to rigorously defined schema or it may simply choose an XML encoding that is convenient for it. Similarly, a computing device consuming XML can choose to verify its contents to ensure it conforms to an expected schema or it can assume the data is correctly formatted and attempt to parse the results. Because tasks such as schema verification can be computationally expensive, when required they are often best done by a server before data is sent onto a device.