 | Level: Intermediate Dethe Elza (delza@livingcode.org), Senior Software Developer, Uniserve Communications Corporation
David Mertz, Ph.D (mertz@gnosis.cx), Author, Gnosis Software, Inc.
09 Jan 2007 Ajax stands for Asynchronous JavaScript and XML and the idea is that with modern Web browsers you can, with acceptable reliability, keep a channel open to the server to pass data back and forth as your Web application is used. This contrasts with standard Web techniques that follow links, causing the entire page to load anew. Many aspects of Ajax-based development require design different decisions than traditional Web pages: How to manage the back button, how to display updated data, how often to send updates, and more. The focus for now will be on just one group of related aspects: what format should the data exchange take?
There are a lot of choices here. The X in Ajax is for XML, but XML is not a language, it is a toolkit for building languages. So your first decision is: do you use an existing language, or build your own? Several tradeoffs are involved. You have to ask if an existing language fits your needs or whether you can design something which is a better fit? Are there tools to process the language, or will you have to build them? If you communicate with others (and if not, why are you building a Web application in the first place?), how well known is the language? Will other applications readily be able to access and use your data?
Some of the obvious choices to pick from are (X)HTML (including the microformat subsets), SVG or X3D if your data is graphical, Atom for snippets of data over time, OPML for simple outlines, and RDF for semantic graphs. At one extreme, you might send DocBook, DITA, or even OpenOffice formatted data, which is rich, semantic, full-featured, and very verbose. (See Resources for more on these formats.)
At the other extreme, you can take a step back and realize that despite the X in Ajax, you can send any kind of data you like. You can send binary data, images, movies, or PDF files; but those are difficult to manipulate in the browser with JavaScript. More readily, you can send text formats that are simpler than XML: tab- or comma-delimited lists, Markdown or other lightly structured text, YAML, or JSON alternatives to XML. Even without using full XML you have dozens of options, thoroughly documented at the XML Alternatives site (see Resources). To summarize, here are a few of your choices along the continuum from most rich (and verbose) to less rich, but simpler. Even within a single item on this list, you can find multiple ways to encode the data, so the ordering is debatable and not to be taken as more than a rough estimate.
- OpenOffice Spreadsheet
- DITA (Darwin Information Typing Architecture)
- DocBook
- RDF-XML
- XHTML
- Microformat
- Atom
- OPML (Outline Processor Markup Language)
- Custom XML
- Markdown / Textile / reStructured Text
- YAML (YAML Ain't Markup Language)
- JSON (JavaScript Object Notation)
- Comma- (or Tab-) delimited text
What should we measure?
With all of these options, how is it even possible to make an informed decision? For several reasons, the above list cannot be in strict order of complexity.
- First, you can use most of the formats in simple ways, or in more complex ways.
- Second, we must distinguish whether the complexity is to create, to read, to parse, or to process? XML by itself is relatively complex, but parsers already exist in the browser, which makes that step simple, for instance.
- Third, complexity depends greatly on what type of data we are talking about. Is it very rigidly structured, like a spreadsheet or a database? Is it very loosely structured, like a word processing document or a blog post? Is it a large document, like an aircraft manual, or a small snippet of
data, like a response code? If the data set is large, do you have to send it all at once, or can you send pieces of it as needed? How difficult is it to divide a large data set into smaller pieces, and how much information will you have to add in order to reassemble the smaller pieces together correctly on the other side?
In other words, what are the most critical factors? They include:
- Verbosity/bandwidth (not as important as you think...except sometimes it is)
- Readability (and writability, and maintainability)
- Ease of parsing (client-side and server-side)
- Speed of parsing (native vs. scripting)
- Information loss (that is, ordered pairs -> dictionary -> sets)
- Flexibility (sometimes less flexible is better, we know what to expect)
- Language portability (how many languages can you use it with?)
- Correctness (how easily can you check to make sure it is conforms to your format?)
- Round-tripping (that is, Markdown -> XHTML -> Markdown, how much data loss is there?)
For the most part, you don't want to optimize for speed, or bandwidth utilization, or any other type of efficiency--but for something more nebulous: user satisfaction. It doesn't matter if there is a slight network delay, if you can keep the delay behind the scenes and make updates appear to be instantaneous. This is, after all, why Ajax is an improvement over generating entirely new Web pages.
Rules of thumb
I'm going to go out on a limb here and give some rules of thumb first, then give some examples to try to justify them. Based on the examples below and my own experience with building Web applications, I've come up with these guidelines for choosing among the plethora of options available when using Ajax techniques. (Editor's note: Dethe Elza is the author for the rest of this article.)
- JSON for Data: If you have structured or semi-structured data, choose JSON. At least three parsers are built into your browser (HTML, XML, and JavaScript), and the fastest one is JavaScript. Also, if you will manipulate the data using JavaScript, you're better off if the data is in JavaScript already, rather than going through all the hoops of DOM manipulation. If your data is not directly for display, or will be modified first, or will be displayed in different parts of the Web page, or in different formats, then JSON is probably a good choice. If you data fits well with a relational database then JSON is probably a good fit. Good libraries for JSON exist for most programming languages, so it's not just for JavaScript anymore.
- XML for mixed content (documents): If what you will post requires the use of metadata (such as URLs) or a varied mix of markup and text, such as word processing documents and blog posts, use XML. If your data will display directly in one place, you can format it on the server and just use Ajax to retrieve it and insert it directly in your document (this technique is sometimes known as client-side includes). As David showed in his MochiKit article (see Resources), you can deliver XML to the browser these days and format it with CSS, or you can deliver HTML and choose to style it or not. I can't provide too much guidance on which XML you should use, except that you want to choose a standard format (such as XHTML, SVG, or X3D.) that provides a good enough fit for your data. Then, use a small subset of that format, to make your data more interoperable with other systems down the road, as well as more familiar to other programmers, and better documented. You can sometimes come off with a good win by creating your own XML format, but it would have to be much improved in some fundamental way to be worth the interoperability headaches that you'll incur. When in doubt, stick with HTML, the lingua franca of the Web.
- Atom for syndication: Here I define syndication pretty widely. If your data will be updated periodically, wrap it in Atom. If your data should be time-stamped, wrap it in Atom. Basically for any flow of data over time, use the Atom format as a standard envelope. That way, you'll have access to many existing tools for tracking your own data and re-using it, through aggregators, newsreaders, and scripting libraries.This way you can insert the data into a Web page, and dual-purpose it to be a syndication feed with little or no additional effort.
 |
The paradox of choice
Now look at other possible formats using the same example data to illustrate the tradeoffs, and how you might use each format. The previous couple columns (see Resources) have used simple examples in order to focus on the mechanisms, but this time I want data taken from a real-world example. My wife, Daniela, is a poet and carefully tracks of her submissions to journals, contests, and other events. She needs to track what stage each poem is in, which ones are accepted or rejected, how much she gets paid for each, how much each event costs her, and other information. Listing 1 shows some of the data, more or less, as it appears on paper:
Listing 1
Room of One's Own
Submitted May 10, '05
* Hyacinth Blue
* Fabrication
* Thanksgiving
* Spilling the Peas
Accepted Hyacinth Blue
Accepted Sept 2005
Published Oct 2006
Paid Sept 2006
Paid $50 + 2 copies
Postage $1.12
Submission Fee: 0
Journal submission
Surrey International Writer's Contest
Contest submission
Submitted Aug. 31 2006
* 13th Child
Fee: $15
Postage: 1.05
Honorable Mention
Prize: $150 + copy of anthology
Accepted Sept. 26 2006
Publication Date Oct. 20 2006
Word on the Street
Public Reading
Invited speaker
Reading time: 10 minutes
Paid: T-shirt and lunch
Date: Sept 24 2006
Paideusis: The Journal of the Canadian Philosophy of \
Education Society
Submitted Oct. 13th 2006
* To carry over: metaphor invents us (seven poems)
Email submission
Referreed Journal
Accepted Oct. 16th 2006
Published (Pending) Nov. 2006
|
This has worked alright for her, but as she sends more and more submissions out, tracking the state of each poem becomes more difficult. It gets harder to track her income and expenses for the year, and she'd like to be able to extract other information, such as average response time (time between submission and getting an acceptance or rejection). So I offered to build her an application, which I call "Fame Not Fortune," and I think it will lend itself well to being an Ajax-driven Web application.
Of course, since I'm lazy, I'd rather use an application that we already have than build a new application. She already uses Open Office (word-processing) (see Resources) to edit her poems, so perhaps she can use Open Office (spreadsheet) to track them. Figure 1 shows what that might look like:
Figure 1. Open Office Spreadsheet example
Already, some problems emerge. In particular, a spreadsheet isn't the most natural interface for tracking this stuff. The data tracked is pretty flexible, so many columns aren't used for each item, and for my target user (Daniela), firing up a spreadsheet is not going to be as natural and easy as going to a Web site. So far my intuition about building a Web app holds up. Of course, since Open Office saves its documents in XML, maybe I can have a "best of both worlds" situation where she can use Open Office for more complex data-mining tasks, but use the Web for her data entry. In that case, maybe keeping the data in one format is a good idea.
In Open Office, the saved format is an .odf file, which is really just a .zip file that contains the data and other resources (embedded images, scripts, styling info, and so on.). Looking inside this very minimal document, I find:
- META-INF, a folder which contains manifest.xml, a list of the contents of the .odf document
- Configurations2, a folder which contains a bunch of UI-related things for status bars, menus, and such. I think I can safely ignore that for now.
- Thumbnails, a folder which contains a small .png image of my document
- content.xml, a file which appears to be the actual data that I entered
- meta.xml, a file which contains info about the document: creator, date modified, and other details.
- mimetype, a file containing the string "application/vnd.oasis.opendocument.spreadsheet"
- settings.xml, a file which appears to contain all the preferences that I set in Open Office
- styles.xml, a file which contains formatting information for my spreadsheet
So, if I want to send data between a Web app and Open Office, what I'm really interested in is not the whole .odf file, but just the inner content.xml. When I look at that, what do I see? Well, it's 17,629 characters long, contains 23 XML namespaces, 63 lines of style information (despite the fact that there is a separate file for styles), and the individual cells also have style information on every cell. These may all be reasonable tradeoffs for a desktop spreadsheet application, but I don't want to spend my time shipping all of this unnecessary information over the network, just to have to parse it, sort through it, and discard it. Listing 2 shows a small snippet, one row of the actual data, for comparison:
Listing 2
<table:table-row table:style-name="ro3">
<table:table-cell office:value-type="string">
<text:p>Room of One's Own</text:p>
</table:table-cell>
<table:table-cell table:style-name="Default"
office:value-type="string">
<text:p>Journal</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce2"
office:value-type="string">
<text:p>Hyacinth Blue; Fabrication; Thanksgiving;
Spilling the Peas</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce5"
office:value-type="date" office:date-value="2005-05-10">
<text:p>10 May 2005</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce5"
office:value-type="date" office:date-value="2005-09-01">
<text:p>1 Sep 2005</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce5"
office:value-type="date" office:date-value="2006-10-01">
<text:p>1 Oct 2006</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce5"
office:value-type="date" office:date-value="2006-09-01">
<text:p>1 Sep 2006</text:p>
</table:table-cell>
<table:table-cell office:value-type="string">
<text:p>Hyacinth Blue</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce6"
office:value-type="currency" office:currency="CAD"
office:value="50">
<text:p>50.00 CAD</text:p>
</table:table-cell>
<table:table-cell office:value-type="string">
<text:p>2 Copies of Publication Issue</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce7"
office:value-type="currency" office:currency="CAD"
office:value="1.12">
<text:p>1.12 CAD</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce7" />
<table:table-cell table:number-columns-repeated="244" />
</table:table-row> |
That's not terrible, but it is enough that I want to look more closely at alternatives. What about embedding the data in XHTML? In that case, I don't need to parse it or format it, I can just display it directly as shown in Listing 3:
Listing 3
<html><body><ul>
<li><dl>
<dt>publisher</dt><dd>Room of One's Own</dd>
<dt>type</dt><dd>Journal</dd>
<dt>titles</dt><dd><ul>
<li>Hyacinth Blue</li>
<li>Fabrication</li>
<li>Thanksgiving</li>
<li>Spilling the Peas</li>
</ul></dd>
<dt>submitted</dt><dd>2005-05-10</dd>
<dt>accepted</dt><dd>2005-09-01</dd>
<dt>published</dt><dd>2006-10-01</dd>
<dt>payment received</dt><dd>2006-09-01</dd>
<dt>titles accepted</dt><dd><ul>
<li>Hyacinth Blue</li>
</ul></dd>
<dt>expenses</dt><dd><dl>
<dt>postage</dt><dd>CAD 1.12</dd>
</dl></dd>
<dt>payment</dt><dd><ul>
<li>CAD 50.00</li>
<li>2 Copies of Publication Issue</li>
</ul></dd>
</dl></li>
<li><dl>
<dt>publisher</dt>
<dd>Surrey International Writers' Competition</dd>
<dt>type</dt><dd>Contest</dd>
<dt>titles</dt><dd><ul>
<li>The Thirteenth Child</li>
</ul></dd>
<dt>submitted</dt><dd>2006-08-31</dd>
<dt>accepted</dt><dd>2006-09-26</dd>
<dt>published</dt><dd>2006-10-20</dd>
<dt>payment received</dt><dd>2006-10-20</dd>
<dt>titles accepted</dt><dd><ul>
<li>The Thirteenth Child</li>
</ul></dd>
<dt>expenses</dt><dd><dl>
<dt>postage</dt><dd>CAD 1.05</dd>
<dt>entry fee</dt><dd>CAD 15.00</dd>
</dl></dd>
<dt>payment</dt><dd><ul>
<li>CAD 150.00</li>
<li>Honorable Mention</li>
<li>Copy of Anthology</li>
</ul></dd>
</dl></li>
<li><dl>
<dt>publisher</dt><dd>Word on the Street</dd>
<dt>type</dt><dd>Invited Reader</dd>
<dt>event</dt><dd>10 Minutes of readings</dd>
<dt>event date</dt><dd>2006-09-24</dd>
<dt>payment</dt><dd><ul>
<li>T-Shirt</li>
<li>Lunch</li>
</ul></dd>
</dl></li>
<li><dl>
<dt>publisher</dt><dd>Paideusis: The Journal of the
Canadian Philosophy of Education Society</dd>
<dt>type</dt><dd>Refereed Journal</dd>
<dt>titles</dt><dd><ul>
<li>To Carry Over: Metaphor Invents Us (seven poems)</li>
</ul></dd>
<dt>submitted</dt><dd>2006-10-13</dd>
<dt>accepted</dt><dd>2006-10-16</dd>
<dt>published</dt><dd>Pending</dd>
<dt>titles accepted</dt><dd>All</dd>
</dl></li>
</ul></body></html> |
This is a fairly simple mapping from semi-structured data to HTML. The default styling isn't much, but it would be very easy to re-style using CSS in a cross-platform way. It is also pretty easy to walk the data using the DOM, and even reasonably self-descriptive. There is a slight bloat from added HTML code, but not too bad. The example is very similar to the XOXO outline Microformat, (see Resources) and would, I believe, be a XOXO outline if I add class="outline" to the first <ul /> element. I could add further semantic content with a custom XML language, replacing the description lists with <submission/> elements, for instance, but for this example I don't gain much in either conciseness or readability. Next I'll try an example yet further down the simplicity axis, using the JavaScript Object Notation (JSON):
Listing 4
{ "publisher": "Room of One's Own",
"type": "Journal",
"titles": ["Hyacinth Blue", "Fabrication", "Thanksgiving",
"Spilling the Peas"],
"titles accepted": ["Hyacinth Blue"],
"submitted": "2005-05-10",
"accepted": "2005-09-01",
"published": "2006-10-01",
"payment received": "2006-09-01",
"expenses": [{"postage": "CAD 1.12"}],
"payment": ["CAD 50.00", "2 Copies of Publication Issue"]},
{ "publisher": "Surrey International Writers' Competition",
"type": "Contest",
"titles": ["The Thirteenth Child"],
"titles accepted": ["The Thirteenth Child"],
"submitted": "2006-08-31",
"accepted": "2006-09-26",
"published": "2006-10-20",
"payment received": "2006-10-20",
"expenses": [{"postage": "CAD 1.05"},
{"postage": "CAD 15.00"}],
"payment": ["CAD 150.00", "Honorable Mention",
"Copy of Anthology"]},
{ "publisher": "Word on the Street",
"type": "Invited Reader",
"event": "10 Minutes of readings",
"event date": "2006-09-24",
"payment": ["T-Shirt", "Lunch"]},
{ "publisher": "Paideusis: The Journal of the Canadian\
Philosophy of Education Society",
"type": "Refereed Journal",
"titles": ["To Carry Over: Metaphor Invents Us \
(seven poems)"],
"titles accepted": "All",
"submitted": "2006-10-13",
"accepted": "2006-10-16",
"published": "Pending"}
] |
Here in Listing 4, you see all of the same content as in the HTML encoding, but even more accessible to scripting because it is simply a subset of JavaScript. You can access the data directly as JavaScript objects, lists, and strings. This format is simple, concise, retains all the information of earlier formats, retains structure well, yet it is still flexible enough for the semi-structured data. This is some good stuff, but surely it can be even simpler. Go back to the first example, using a spreadsheet to hold the data. A common method for transferring data from one spreadsheet to another is to use comma-separated value (CSV). Using this time-tested format, you get the following:
Listing 5
"Publisher", "Type", "Titles", "Submitted", "Accepted/Rejected", \
"Published", "Payment Received", "Titles Accepted", "Payment", \
"In Kind", "Postage", "Fees"
"Room of One's Own", "Journal", "Hyacinth Blue; Fabrication; \
Thanksgiving; Spilling the Peas", 10 May 2005, 1 Sep 2005, \
1 Oct 2006, 1 Sep 2006, "Hyacinth Blue", 50.00 CAD, \
"2 Copies of Publication Issue", 1.12 CAD,
"Surrey International Writer's Competition", "Contest", \
"The Thirteenth Child", 31 Aug 2006, 26 Sep 2006, 20 Oct 2006, \
20 Oct 2006, "The Thirteenth Child", 150.00 CAD, "Honorable Mention, \
Copy of Anthology", 1.05 CAD, 15.00 CAD
"Word on the Street, Vancouver", "Invited Speaker", \
"10 Minutes of Readings", , , 24 Sep 2006, , , , "T-Shirt, Lunch", ,
"Paideusis: The Journal of the Canadian Philosophy of Education \
Society", "Refereed Journal", "To Carry Over: Metaphor Invents Us \
(seven poems)", 13 Oct 2006, 16 Oct 2006, "(Pending) Nov 2006", , \
"All", , , "Email",
|
OK, Listing 5 proves that it is possible to go too far along the simplicity axis. I also want to point out an important difference between JSON and CSV: while CSV is a common technique, it is by no means standardized, and generally assumes only ASCII text, while JSON is clearly and canonically defined and specifies the use of the UTF-8 encoding of Unicode. So while this particular example does not use any text outside of the ASCII range, JSON (and XML) work with international text.
The Atom connection
The Atom Syndication Format has some overlap with the information tracked by Fame not Fortune: author, publication date, and so on. I could put all the data into one feed and then format the XML on the page, but also allow it to be tracked with a standard aggregator. This could be an important differentiator between my application and all of the other tools for helping poets track their publications. Listing 6 shows what the Atom feed (with only one entry for brevity) might look like:
Listing 6
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Fame not Fortune</title>
<subtitle>Recent submissions</subtitle>
<link href="http://example.org/famenotfortune"/>
<updated>2006-12-03T20:37:16Z</updated>
<author>
<name>Daniela Elza</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Hyacinth Blue</title>
<link href="http://example.org/famenotfortune/hyacinthblue"/>
<id>urn:uuid:68C0BAAB-C955-45F9-BDD6-21A22FC809AF</id>
<updated>2006-12-01T20:37:16Z</updated>
<published>2006-10-01T12:12:12Z</published>
<category term="Journal"/>
<content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">
<dl>
<dt>publisher</dt><dd>Room of One's Own</dd>
<dt>titles</dt><dd><ul>
<li>Hyacinth Blue</li>
<li>Fabrication</li>
<li>Thanksgiving</li>
<li>Spilling the Peas</li>
</ul></dd>
<dt>submitted</dt><dd>2005-05-10</dd>
<dt>accepted</dt><dd>2005-09-01</dd>
<dt>payment received</dt><dd>2006-09-01</dd>
<dt>expenses</dt><dd><dl>
<dt>postage</dt><dd>CAD 1.12</dd>
</dl></dd>
<dt>payment</dt><dd><ul>
<li>CAD 50.00</li>
<li>2 Copies of Publication Issue</li>
</ul></dd>
</dl>
</div>
</content>
</entry>
</feed>
|
If the above (Listing 6) looks familiar, it's because an Atom Entry element does not have all the fields needed for the data we are sending, so most of the entry is the XHTML example from above, wrapped in the <content/> tag. I was able to repurpose the published field and the author, but not much else, and really it is an abuse of the published field, which should be the date of the publication of this entry, not of the data it contains. I could extend the Atom Entry with additional fields by creating my own namespace for them, but no existing aggregators or feed readers would be able to use that information, rendering it invisible, and therefore pointless for this purpose. I could simply wrap my XHTML example in an Atom envelope to bring syndication support to my application, but from a purely data-oriented view, Atom is not bringing me any advantages. Now, when I want to move data into and out of my application, wrapping in Atom Entries and using the Atom Publishing Protocol (see Resources) might be a big win. Note that if I want to use Atom, that does constrain my data format choices: The Atom <content/> tag can hold three possible types of data: text (which could be our JSON format), HTML with all entities escaped, or XHTML. There is no provision to embed arbitrary XML content in Atom without extending Atom first, although you can provide links to such data. So it is important to decide early if you will want to provide a syndication stream for your data, because if you want Atom integration that will influence your other data format decisions.
|
Making an example
You make a lot of decisions when you build an Ajax-enabled Web site or Web application. What format your data takes is a decision that is too often made by default or without really thinking about all the issues. I have tried here to at least give some food for thought on these issues and to help frame the decision making process. To reiterate the rules of thumb given above:
- JSON for data
- XML for documents (favoring XHTML unless there is a reason not to)
- Wrap it in Atom for syndication (and to support the Atom Publishing Protocol)
I tried to show a lot of examples to illustrate some of the tradeoffs involved and to support my rules of thumb. I haven't proven anything, because these are issues that are all special cases and most real-world examples will be full of exceptions to any rule. These guidelines have worked for me, perhaps they can save you some time and effort. I hope to report back in a future column about actually building the site using these guidelines. As always, I'm interested in hearing your success stories, criticisms, and ideas.
Resources Learn
- XML Alternatives: Consider over 100 formats which the mysterious PaulT enumerates as alternatives to XML.
- XML Matters: MochiKit (David Mertz, developerWorks, November 2006): Take your XML manipulations way beyond the DOM with the MochiKit JavaScript library.
- XML Matters: YAML improves on XML (David Mertz, developerWorks, October 2002): Check out YAML, a data serialization format that can be easily read by humans and is well-suited to encoding the data types used in dynamic programming languages.
- Ajax: A New Approach to Web Applications: Read Jesse Garrett's original article that introduced and defined Ajax as a programming model.
- Microformats: Visit the home site for microformat specifications: hCard, hCalendar, XOXO, and more. XOXO in particular is a microformat for using XHTML list elements as an outline format.
- Introducing JSON: Explore Douglas Crockford's site, which brought JSON to the world. Includes links to articles, examples, and libraries for using JSON with many different programming languages.
- Markdown: Check out John Gruber's lightweight markup dialect that is very well suited for writing text for the Web.
- Textile: Compare Dean Allen's format for lightweight markup, with a different set of features than Markdown including some extensibility.
- OPML (Outline Processor Markup Language): Try Dave Winer's format for simple outlines.
- SVG: Scalable Vector Graphics: Read this XML standard for 2D vector graphics.
- X3D: 3D for the Web: Dig into the XML standard for 3D graphics.
- Docbook: Look into an XML format for technical documentation and rich data exchange.
- Introduction to DITA (Don Day, Michael Priestley, David Schell, developerWorks, September 2005): Read up on the Darwin Information Typing Architecture, an XML format structured around topics rather than documents.
- Thinking XML: The open office file format (Uche Ogbuji, developerWorks, January 2003): Try this XML format on an open XML DTD for front office documents.
- RDF/XML Syntax Specification (Revised): While RDF does not specify a particular representation, explore how the XML syntax fits it into the Ajax ecosystem.
- The Atom Syndication Format: See how this useful wrapper provides a variety of metadata, such as author, timestamps, or alternate data sources, around your messages.
- IBM XML certification: Find out how you can become an IBM-Certified Developer in XML and related technologies.
- XML technical library: See the developerWorks XML Zone for a wide range of technical articles and tips, tutorials, standards, and IBM Redbooks.
- developerWorks technical events and webcasts: Stay current with technology in these sessions.
Get products and technologies
- Simple JSON: Get a python library for parsing and serializing JSON data safely.
- IBM trial software: Build your next development project with trial software available for download directly from developerWorks.
Discuss
About the authors | 
| | Dethe Elza writes about having fun with your computer, and making it work for you rather than the other way around, at http://livingcode.org/. He can be reached for suggestions and recommendations at delza@livingcode.org. |
| 
| | David Mertz wishes easy things were easier. David can be reached at mertz@gnosis.cx; his life pored over at http://gnosis.cx/publish/. Suggestions and recommendations on this, past, or future, columns are welcomed. Check out David's book "Text Processing in Python" at http//gnosis.cx/TPiP/. |
Rate this page
| |
