The XML e-Learning Revolution: Is Your Production Model Holding You Back?

In this article, we will present the contrast between HTML-based and XMLbased e-Learning and explain the advantages of the latter. We will also provide an extensive example of the way to develop an XML Schema that will enforce the instructional designer’s pedagogical decisions uniformly across the development team, including the subject matter experts. Finally, we offer two testimonials, if you will, about XML-based e-Learning development, one from higher education and one from the corporate world.

The HTML approach to development

HTML is a scripting language designed for creating documents for display in a Web browser. HTML defines the visual layout of those documents, and enables their connection to other documents by using hypertext links. Using a modest list of formatting options, HTML allows document authors to combine text, multimedia assets, and navigation links and to determine how the documents will appear in a Web browser.

Though effective, HTML has its limitations. By locking the content and the rules for presenting that content together into a single document, HTML makes content reusability difficult. The content formatting in an HTML document provides one specific visual layout, and it works only in a Web browser. Presenting that content in alternate visual layouts or delivery mediums involves re-authoring it for each new layout or medium.

Ideally, you would want to be able to change the visual layout of e-Learning content or the medium via which it is delivered, such as print or PDA, without having to repeatedly revisit the authoring process. To accomplish this requires separating content from both its layout and from delivery mediums. Content then becomes highly reusable, and you can present it more readily in different delivery mediums to a variety of audiences.

This separation also facilitates the assignment of conditions for the presentation of content. In other words, a content management system can automatically identify learners in a given audience, using a certain kind of device, and deliver the content using the most appropriate presentation, via the most appropriate medium.

Unfortunately, because of its rigidity, HTML makes it impossible to effectively separate content from its presentation. If HTML is so limited, why is it so prevalent?

Successful e-Learning production requires a combination of skills. A highly technical team of graphic designers, programmers, and audiovisual specialists could create a visually compelling, interactive Web project, but there is more to e-Learning. It also takes the expertise of subject matter experts (SMEs) and instructional designers to deliver on the educational goals inherent in such an endeavor.

Because their strengths are in educational subject matter knowledge and (perhaps) in copywriting, SMEs may not be highly proficient with the technical components required. As a result, WYSIWYG (What You See Is What You Get) HTML authoring tools have become popular. These tools promise that, given the requisite skills to create a PowerPoint presentation, a SME can produce an e-Learning project. This allows SMEs to work without technical resources, and for many organizations eliminates the bottleneck created by a huge base of SMEs and a small technical team.

This is the main reason that HTML-based solutions are so entrenched in the e-Learning community. The biggest question left unanswered by this approach is, “Where is the instructional designer?” Just as the invention of the word processor did not turn every WordPerfect user into a great novelist, skill with PowerPoint and Dreamweaver does not make someone an instructional designer. However, the apparent convenience of PowerPoint and the WYSIWYG HTML editors has encouraged many organizations simply to direct the SMEs to proceed without the technical team and without the instructional designers. This has resulted in a large amount of e-Learning that is not visually compelling, interactive, pedagogically sound or engaging for the learner.

Any solution that is going to raise the quality of e-Learning must also enforce pedagogy — the strategies used to focus instruction and improve learner outcomes — and facilitate good user interface design. It must also include far more energizing content than a long sequence of text slides and bullet points. However, at the same time, the solution must not become a bottleneck to the work of the SMEs or greatly increase the costs or timelines of e-Learning projects. In fact, to be successful, the solution must reduce them.

So, if having SMEs going around the instructional designers and the technical team is one of the drawbacks to HTML-based solutions, what’s the answer? One of the most important contributions that instructional designers make to an e-Learning project is the development of a consistent pedagogy. There are many competing opinions and ideas as to what constitutes good pedagogy. As a result, different organizations will require different pedagogical approaches from their instructional designers.

Some HTML-based tools have tried to incorporate the enforcement of a standard pedagogy. However, the pedagogical requirements of e-Learning projects — whether there will be remediation when a learner responds incorrectly, for example, or the number of quizzes and criterion tests, how to handle simulations and games, and so on — may differ from one organization to another or between instructional designers. As a result, none of the HTML-based tools can deliver a definitive, global, final word on the best pedagogical design.

Ideally, a tool should make it possible for each organization to determine its own pedagogical design and, at the same time, to apply that design consistently, without fail, across all work done by an organization’s SMEs.

XML to the rescue

XML is the eXtensible Markup Language. It allows semantic content markup. Markup is information added to a document that enhances the meaning of the document in certain ways. Unlike HTML, XML says nothing about what things look like. Instead, XML focuses all its efforts on the semantic content: declaring what things are. Furthermore, XML allows you, the developer, to define markup to describe things found in an XML document. A simple example of XML would look like this:

XML’s structure appears similar to HTML because it is also a tagging language. XML is both machinereadable and human-readable and is immediately understandable because the tags give semantic meaning. XML says nothing about formatting.

There are many ways to format XML documents. One option is to format XML documents for use in a Web browser, using the eXtensible Stylesheet Language or XSL. Alternately, you may pull an XML document into a Flash file and format it accordingly. If you want to send an XML document to PDF, you can determine the formatting with the eXtensible Stylesheet Language for Formatting Objects, or XSL-FO. In short, the possibilities to format for different visual layouts and delivery mediums are virtually unrestricted. (Editor’s Note: Excellent free basic tutorials are available online at http://www.w3schools.com/default.asp on the subjects of XSL, XSL-FO, XSD, and other XML topics related to this article.)

Before creating an XML document, it is a best practice to create an XML Schema Definition, or XSD. An XSD defines the tags in an XML content document, and the rules of use for those tags. You write the XSD itself in XML. The XSD defines and enforces the rules of use, so that SMEs only need to use the tags available, at any given time, to mark up the content they are authoring. SMEs don’t need to know or care about the final layout or delivery medium.

This separation of content from its presentation is extremely powerful. It allows one set of rules to dictate the document’s structure and any number of rules for how to format all content written using that structure. In addition, because XSL is a conditional language, you can display certain content in some media and not in others, rendering the same content differently to different audiences.

In the context of e-Learning, an XSD lets an instructional designer define the pedagogical structure and forces all SMEs to follow that structure. For example, if an instructional designer has determined that all lessons are to start with a list of objectives, followed by a pre-test, examples, a practice exercise, and finally an exam, then the designer can define this structure in an XSD. Additionally, the designer would also define all the possible elements, or tags, for each of those objects (pre-test, example, exercise, and exam). As a result, all SMEs are able to author independently, without risk of deviating from the enforced structure. Creating an XSD is similar to database design. Create a set of elements, define their type value (string, integer, etc.), make them required or optional, and determine their relationship to other elements within a document.

Now, HTML also has a Schema. It is loose and browsers do not enforce it, but it does exist. Consider this: there is a <table> element in the HTML Schema. The <table> element has attributes, such as border, cellpadding, cellspacing, align, etc. The <table> also contains other elements: rows and columns, or <tr> and <td>; respectively. The HTML Schema says that a <table> element can contain x number of <tr> elements and a <tr> can contain x number of <td> elements. HTML is a markup language derived from the print industry, so it describes page layout and does not actually describe the content. But you can see how the Schema describes what the page should contain and these sets of rules allow browsers to know what elements are on an HTML page.

With an XML Schema it is possible to develop an even more robust and definitive document to describe, enforce or constrain any instructional style.

Choosing page types

Suppose that an instructional designer decides on a pedagogical structure limited to three kinds of displays that a learner will see. Think, for the sake of this discussion, of each of these displays as being a “page.” A learner may, at any given time, be looking at a page of objectives, a page of instructional content, or a page with a test of some kind on it. We will call these, respectively, an objectives page, an info page, and an assessment page.

Making this decision about page types is one of the first steps in developing an XML Schema for e-Learning. Each page type becomes an element in the Schema. This is usually the shortest list of elements and allows for concentration on a shorter list of specific elements included in each of those page types. Remember, the Schema can evolve over time, so you haven’t written your initial choices in stone. For e-Learning, the type of content is the key to the page type. Each page contains one type of content, such as objectives, or information, or assessment. Each page will contain various kinds of information relating to the page type. For example, an objective page will have an introduction, objective(s), and perhaps a summary. An information page might have text, audio, animation(s) or other instructional content on it.

Every Schema must start with a root element. For the purposes of this example, we define this element as <sco> (Shareable Content Object). All other elements will be children of the <sco> element.

Here is the definition of the <sco> element:

The next step is to define the page types. In this example, they are <objectives_page>, <info_page>, and <assessment_page>. Here are the definitions:

Add these elements to the root <sco> element. (See Figure 1.) By doing this, the <sco> element becomes a complex type, since it now contains other elements. This is where you start applying the rules for these elements, which in turn controls what the SMEs can do when they author lessons.

Complex types require indicators, which control the use of elements in documents. Some of the indicators for the child elements (the ones within the <sco>) in this example define the order of the elements. These are called, logically enough, order indicators, and there are three of them. They are <sequence>, <choice>, or <all>. The <sequence> indicator specifies that the child elements must appear in a specific order. The <choice> indicator specifies that either one child element or the other can occur (there can only be two child elements, in other words). The <all> indicator means that the child elements can appear in any order, and that each must occur only once.

There are other kinds of indicators, as well as different kinds of complex elements. We will explain these as they appear in the definitions later in this article.

For this example, a <sequence> indicator enforces that an <objectives_page> comes before an <info_page> and an <info_page> comes before an <assessment_page>. This is what the definition looks like:

Elements may also be optional or required (by default, within a <sequence>, they are required). You can control the number of allowable elements by using an occurrence indicator. There are only two occurrence indicators: <maxOccurs> (sets the maximum number of times an element can occur) and <minOccurs> (sets the minimum number of times an element must appear, with a default value of 1).

For example, the definition can make the <assessment> page optional. At the same time, you may want to allow the SME to add as many <info> pages as needed. Set the maximum occurrences to “unbounded” and the minimum occurrences to 0, respectively, to make this happen:

After defining the three page types, the next step is to decide what elements each page can contain. This is where you define the elements that make up each page and give them meaning. Thinking out of the box is very important for this step. This is not about colors, image placement, alignment, etc. Now is the time to consider what each element contains and when it should appear within the document.

The objectives page

Broken down to its basic elements, an objectives page should contain the following:

• Some brief text describing the and any possible prerequisites or other knowledge that may be required.
• A list of objectives or outcomes.
• Perhaps a conclusion, or brief text, summarizing the objectives. These elements would commonly be described as , and
  . The definitions would look like this.

  <xs:element name=”intro”/>
  <xs:element name=”objectives”/>
  <xs:element name=”summary”/>

Now that these elements have names, we need to describe what they are. Applying complex element types will accomplish this. There are four kinds of complex elements: those that are empty, those that contain only other elements, those that contain only text, and those that contain both other elements and text. We specify the type of complex element by adding an attribute to the definition.

For example, <intro> and <summary> elements should be nothing more than text. The attribute to designate an element as “text only” is type=”xs: string”. The definitions now look like this:

However, there is more to think about and to take into account. The <objectives> element should contain more than just text. An <objectives> element could contain multiple <objective> elements (notice the difference in the name), each of which would contain only text.

To be certain that each <sco> contains, for example, at least one, and up to as many as five objectives, add a maximum and minimum occurrence to this element. (See Figure 2 for a diagram.)

Info page

Info pages should be more complex than objectives pages. This is where the actual instruction takes place.

Some of the basic elements an info page may contain are:

• <text_block>
• <call_out>
• <animation>

This list could become very extensive. For the purposes of this article, these three elements will suffice. Obviously a <text_block> will contain text, but it also may contain other elements, such as:

• <emphasis> — used to draw attention to a word or words
• <heading> — delineating the start of a major section of content
• <subheading> — delineating the start of a minor section of content
• <weblink> — text that will link to a Website

This means that the <text_block> is a mixed complex type and requires an appropriate attribute in the definition.

The <text_block> child elements would all be optional for the SMEs use. Here is the Schema (see Figure 3 for the diagram):

The next step is to add a ”source” attribute and a element to the element. The ”source” attribute will provide a URL or directory path to the animation file. The can be descriptive text for screen readers or it can be available for conversion to PDF output. This makes the element a mixed complex type. (See Figure 4.)

Assessment page

Many types of assessment questions could appear on this page. To keep things simple, We’ve used a multiple choice question. Broken down to its basic form, a multiple-choice question would consist of the following elements:

• <question>
• <instruction>
• <option>
• <correct_feedback>
• <incorrect_feedback>

The Schema representation would look like this (see Figure 5 or the diagram):

To provide a way to determine the correct option, add a ”correct” attribute to the option element.

This element is “boolean” (specifies true or false) and it is required.

A completed Schema

This example has focused on page types. This is a common approach, but only one of the many ways of looking at the semantic structure of e-Learning. In the example in Figure 6 you see a very tightly defined model. (This example took only about 20 minutes to create, by the way.) Here each is a set of predefined steps with very few choices for the SME to make about the flow. Notice again that only the structure is defined, not the presentation.

The model calls for an introduction that may include a text area and an image. Next, the has a set of questions with a minimum of one question and a maximum of five. The SME author gets a choice between using multiple choice or true and false questions. Next, there is a lesson that has a textual element and then a case study. Following this is an activity where the user completes a scenario. Finally, the learner completes a post-lesson test that will deliver a mastery score.

Available tools

In the examples in this article, you can see that the instructional designer determines how rigid or how open the structure is.

Knowledge of code is not necessary to create an XSD. Many tools are available that let you drag and drop elements into a flow chart to define your Schema. Two of the tools that many designers use are Altova XML Spy and Stylus Studio.

Once you have defined a Schema as an XSD there are many options available for delivering it to SMEs. SMEs can author XML content documents using XML Spy, Authentic, X-Metal, Oxygen, Microsoft Word 2003 (with some caveats) and many other editors. There are even a few LCMSs, such as Thinking Cap®, that integrate XML authoring into the entire e-Learning production process. Most of these editors simply require an author to right click and select (from a context-sensitive list) the element they wish to add to their document. What is important is that the Schema is completely portable. It is not bound to any one of these systems.

Structured content in practice

We would like to present two brief stories about using XML-based solutions to create e-Learning. The longer of these stories is set in an academic institution. We also have one very brief corporate example to share. We hope that these help you understand the challenge and the promise inherent in converting your production model from HTML-based to XML.

McMaster University

McMaster University’s medical school — famous for implementing problem-based learning in medical education — needed to expand its use of e-Learning during a time of curriculum renewal. At first, the school delivered case studies to students with a combination of print and HTML-based Web delivery. This method was administratively “clunky,” and required editing and updating two separate files any time there was a change. Moreover, there were inconsistencies in the instructional design of the two sets of materials, due to the free-form nature of word processing and HTML formats.

The initial approach to implementing an XML-based solution was to analyze the existing content and e-Learning goals with an eye to instructional design. In other words, designers asked how the pedagogical materials were structured, and then began defining the content with XML Schemas.

The XML-based approach that separates content from presentation layer has enabled single-source publishing of the same content to both print and Web. By describing the content using a Schema, and then creating the XSL-FO for print and the XSL for Web, McMaster has been able to facilitate publishing to different media, to different audiences; with customized content for students and instructors, and for different levels of expertise. (See Figure 7 for an example of context-sensitive feedback based on the learner’s expertise.)

The semantic focus of XML has also imposed a more consistent pedagogy on e-Learning case studies, where the XSD can define topic-specific elements such as “patient history,” “laboratory investigations,” and “diagnosis.” By pre-defining the sequence of page types, and constraining the different elements of a medical e-Learning module, instructional designers have brought consistency to the pedagogy of problem-based e-Learning for medical education. There is also the flexibility to define different schemas for different instructional contexts or content. For example, case studies may have a specific, consistent instructional design; whereas more directive e-Learning content (regarding a specific disease), may have another well-defined schema and content architecture. This enables instructional designers and subject matter experts to have both flexibility and consistency.

The constraints of the Schema are also helpful to subject matter experts, who are otherwise often overwhelmed by the phenomena of “not knowing where to start” when building e-Learning content. The Schema can essentially guide the subject matter expert with an instructional design template, helping to simplify and accelerate content development.

In addition to single source publishing, personalizing content to target audience, and templating of instructional design, XML’s separation of content from presentation has had several advantages for e-Learning implementation. McMaster enjoys a number of collaborative partnerships with other institutions. The ability to author in XML using an XML LCMS, with different XSL “presentation layer” templates, allows for a flexible “co-branding” of the e-Learning delivery (each delivery under the branding and logo of the corresponding institutional partner) without changing authoring tools.

The standards-based use of XML for e-Learning authoring — including the SCORM 2004 standard — has also made the content somewhat independent from proprietary LMS solutions. Content authored in XML is easier to export into different LMSs, extending the reusability of the content. This also reduces some of the panic of being “locked in” to a particular HTMLbased LMS vendor, where the content is often tied to the platform. Although e-Learning can be authored in XML using WordPad and other text editing tools, more sophisticated tools (as discussed in “Available tools”) facilitate schema authoring. Macromedia Flash’s improved handling of XML has also made for a robust linkage between XML at the content end, and Flash at the presentation layer. Moreover, XMLbased LCMSs, such as Thinking Cap and Learn eXact, also help in the management of large scale XML e-Learning deployments by linking asset repositories, schemas, learning object content authoring, and XSL “delivery templates” with the other features of an LMS.

There are challenges in transitioning to an XML approach to e-Learning. First, it involves a more conscious pedagogical approach to your content. Developing a schema requires analysis and thought about your instructional design choices. Authoring content in HTML — a formatting language — doesn’t really require you to commit to semantic choices about your content. HTML gives you flexibility, but at a price: inconsistency between authors. Second, the use of XML requires the additional step of describing the “delivery templates” or formatting instructions in detail. Arguably, both XSL-FO (for PDF and print output) and XSL (for transforming XML to HTML) are more complicated than HTML. In McMaster’s implementation, XSL — the delivery templates for the e-Learning schemas — has proven to be one of the biggest challenges. Once the XSL is in place, however, implementation is complete; and subject matter experts can continue to work on content authoring, without having to worry about formatting issues. An important step in the use of XML is therefore to sort out and simplify the schemas as much as possible. The clearer the XSD on page types and their elements, the easier it is to develop the XSL.

For larger scale e-Learning operations such as enterprise-wide solutions, the benefits of XML are easily realized in reusability of content, flexibility of single-source publishing, the ability to change the presentation layer, and the improved quality and consistency of instructional design at the level of the schemas used for content authoring. For smaller “oneoff” projects, there may be less to gain by abandoning the WYSIWYG of HTML.

Corporate use

While the use of Schemas in higher education at institutions such as McMaster University, Queen’s University, and the Association of Canadian Community Colleges is significant, it is equally relevant for corporate users such as CGI, Teranet, CAE, and Cellular One.

We asked Laura Micks, Manager of Training at Teranet Inc. to tell us about her company’s experience with XML-based e-Learning production. She provided us with this statement, and a screen shot to illustrate one of the courses as delivered online from XML documents (see Figure 8).

Laura said, “We have a large base of subject matter experts, a small team of trained instructional designers, and a smaller pool of technical resources that are available for the creation of new courses. Working from a defined schema lets us get the most out of all the core team, and removes bottlenecks common in the development process. The final result is award-winning training materials, faster, and at significantly less cost than HTML.”

Conclusion

Though heavily entrenched and widely used within the e-Learning industry, HTML production models have a number of drawbacks. By locking content and presentation together in a single document, HTML limits content reusability, facilitates deviation from pedagogical structure, and restricts an organization’s ability to use their resources to their full potential.

In contrast, by separating e-Learning content from presentation, the XML production model provides opportunities and efficiencies in every area where HTML presents obstacles. From its ability to streamline the production process to its emancipation of educational capital, the XML e-Learning production model has the power to spark a revolution in e-Learning.

This revolution must come from instructional designers. By embracing XSD as a means to communicate and enforce pedagogy, the opportunity to create great e-Learning and to share and contrast differing pedagogical models is within the industry’s grasp.