Manage Learn to apply best practices and optimize your operations.

BAM! Kick your metadata up another notch

BAM! Kick your metadata up another notch
Ed Tittel

In my last two tips, I've walked you through DTDs that we built for our test engine that lets us build question-and-answer sequences and questionnaires of all kinds. Today, I'll talk about the metadata that we capture at the course level to help us manage related content modules (which we call lessons), lesson review questions, final exams, and other information we deliver to our online students, and make available to our instructors.

To begin with, let me explain exactly what our online course DTD captures:

  • It identifies each course uniquely with an auto-generated course prefix.
  • It defines e-mail addresses for student agreements, instructors of record, and our software support team, so that we can dynamically insert their e-mail addresses into HTML pages generated on the fly.
  • It defines access controls for three categories of users: guests who can access only the first lesson of any course, students who have not yet approved a student agreement and can only access the rules of engagement and a course overview, and students who have approved that agreement to gain full access to a course's complete materials. We're currently working on adding a fourth category that recognizes instructors or developers who obtain immediate and complete access to all course elements (so far, this hasn't been needed because we've only used this tool in-house, but we're getting ready to extend our licensing to a third party who needs such access).
  • Right now, we also point to a file that lists all course component elements, including key resources such as lesson files, lesson reviews, final exams, and so forth. We're in the process of designing XML to capture all this information explicitly. That will increase the number of elements in our DTD but will also make a lot of implicit information stored in other files readily available through a single interface.
  • We define root URLs where course materials reside, and where individuals go to log in, where they present an account and password to access course materials. This lets us define multiple login instances (and thereby run simultaneous versions of the same classes in parallel, each with separate student databases).
  • We define multiple e-mail message types, so we can dynamically complete pre-defined templates with login and session information for signup, course activation (after students approve a course agreement), and receipt notification for final projects in classes that require them.
  • Finally, we track all previously taken classes in a given semester for which databases are available (to instructors) online, and provide a mechanism to make signup, activation, and access to currently open classes accessible to students.
This metadata has made it easier for us to organize and deliver classes online. In the past 6 months, as we got comfortable with what XML metadata can do, we kept finding new ways to extend and improve on our data representations. This led us to the most profound moral of this story: we've learned we can extend XML documents to add new elements and/or attributes as needed. Furthermore, we've been able to migrate data from older, un-enhanced forms into extended forms easily. My lead programmer, Dr. Bill Brogden calls this "slurping the data" using XSLT or Perl-based tools.

We've actually had an easier time letting our evolving understanding of our needs shape the XML that captures metadata than we ever expected. Bill put it eloquently: "The nice thing about using XML is that it supports gradual changeover in our environment. We can evolve document structures as needed without lots of extra redesign or programming." From somebody with nearly 30 years in IT, that's pretty strong talk!

Other benefits of our approach include:

  • We keep finding new ways to tease data out of our online environment. For our local community college, we plan to capture all course catalog information about classes dynamically, so we can use their labels and terminology straight from the source.
  • We're planning to add explicit content identification and management data to this metadata (it now resides in an external file identified through a CourseControl element in our current XML notation). This should let us enumerate all lesson files, review question scripts, final exam scripts, tips, and ancillary reading materials as part of a native XML course description, instead of managing it externally.
  • Our current structure support "cookie cutter" (cut and paste) creation of new classes, new sections, and other data as needed. All we have to do is copy an existing data structure at the same level, then edit the copied element content and attribute values to make necessary changes. This is far faster than building new data from scratch.
  • We use a validating XML parser to check course description files for completeness and correctness. This makes quality control on what had been an ad hoc project management task easier to test and correct than it ever had been before.
What works for us can also work for you! Try organizing your content and capturing its structure and semantics using XML. You'll be surprised how easily you can accomplish this task, and how simple it is to refine your representation as your understanding of your data modeling needs evolves. In the immortal words of the Alka-Seltzer commercial: "Try it! You'll like it!"

Send an e-mail to Ed at if you want a copy of the course DTD and some sample markup, or if you have comments or questions on this or other XML topics. We're sold on this approach, and would like to sell you on it, too...

Ed Tittel is a principal at LANWrights, Inc., a wholly owned subsidiary of 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? Love it or hate it, why not drop us a line and let us know?
This was last published in February 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.