Manage Learn to apply best practices and optimize your operations.

The X marks XML's sweet spot (or, the value of metadata)

The X marks XML's sweet spot (or, the value of metadata)
Ed Tittel

As somebody who writes about XML and XHTML topics regularly, I am often asked if XML is really necessary or useful, especially by those who can meet their information access and delivery needs using HTML. My answer to that question is a common answer to many real questions in life--namely "That depends..." But because my company has recently been able to solve some thorny problems using XML that illustrate the profound value of metadata (or data that itself describes other data) I believe we've rediscovered some of the core reasons why XML is so useful for information capture and delivery.

We offer online classes through our local community college on a variety of Web-related topics, including XHTML, XML, TCP/IP, and more. It's a busy environment, where we may offer as many as four sections of any of 7 online classes in a given semester, where each class has its own particular collection of lessons, review questions, exercises, and links to external resources and reading assignments.

Until recently, we relied on quite a bit of manual configuration work to set up each section of each class. This included start and end dates, link-checking, changes to external resource and reading assignment links, and so forth. As we were cleaning up between semesters over the holidays, we had a meeting wherein the statement "Gee, wouldn't it be nice if we could just use an arbitrary description of a course to pull all the various pieces together," caused several of us to realize simultaneously that this kind of thing is exactly what XML is designed to do.

From this meeting our "course description metadata" project was born. After a couple of days of design work, and a couple more days of testing and tweaking, we devised a set of XML markup that not only lets us manage start and end dates, establish sets of student IDs and passwords to control logins to each class, and manages the resource and reading pointers, but also lets us describe our classes more abstractly. We had initially taken the quick and dirty approach of deciding that all classes would consist of 6 lessons, with an introductory lesson, and a follow-up final exam, but as our number of classes increased, we realized that this was a kind of Procrustean bed into which all classes wouldn't fit comfortably.

Thus, we devised as complete a set of course description metadata as we could devise, including not just the items already mentioned, but also the number of lessons in the course, the number of sets of review questions and exercises associated with each lesson, and a mechanism to govern the selection of end-of-lesson review questions and final exam questions from the same overall course question bank. All of this metadata is captured in a two-page DTD that we generated automatically from a relatively simple set of markup that we derived from an analysis of our course contents and information that surrounds any given instance of a course.

Now, we're working on another layer of abstraction that will arrange the metadata for an individual course instance within a calendar of courses for an entire semester. This will let us configure our course offerings as if each course was an object in a calendar-based collection of such objects, so that we can not only deal with a course at a time (itself pretty desirable from an automation standpoint) but also so we can deal with an entire collection of courses on a per-semester or yearly basis.

By allowing us to represent the kind of organization our data needs, and capture the underlying information (start and end dates, assignments, exercises, test questions, text modules for lessons, and so on and so forth), XML makes it possible for us to create a single coherent system that handles our current needs. Because the X in XML means this organization is extensible, we can add to our current structure as we learn more about needs that haven't made themselves known yet. Best of all, it means we can use mechanical validation tools as we put individual classes together, and do the same with entire sets of course offerings, to make sure we haven't missed anything, and that all the pieces fit together the way they're supposed to.

Even if you don't offer online courses like we do, I bet your organization has its own unique information gathering and processing needs that would benefit from the kind of capability I've described here. And that's the real value of XML, and what makes it both useful and necessary in a modern IT operation--namely that you can build a set of structures relatively quickly and easily to handle problems and improve efficiency in your organization!


Ed Tittel is a principal at LANWrights, Inc., a wholly owned subsidiary of LeapIt.com. LANWrights offers training, writing, and consulting services on Internet, networking, and Web topics (including XML and XHTML), plus various IT certifications (Microsoft, Sun/Java, and Prosoft/CIW).

Did you like this tip? If so, or it not, why not let us know? Or go to our tips page, where you can submit your own tip, or rate this, and other tips.


This was last published in January 2001

Dig Deeper on Development implications of microservices architecture

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

DevOpsAgenda

Close