XCRI's decision to be informed but not constrained by the Norwegian CDM schema has placed emphasis on developing a new XML schema that is sufficiently flexible to cope with the curriculum information needs of Further and Higher Education in the UK. Work has therefore been undertaken over the summer to appreciate those needs and to develop an XML schema capable of modelling relevant information. XCRI's research assistant, Julie Hardman, has reviewed 160 online prospectus entries to test the sufficiency and appropriateness of a set of XML elements identified through consultation with XCRI partners and site visits to institutions. In parallel and with considerable email discussion, Ben Ryan (Technical Director of KaiNao) has been developing an XML schema for the Pathways For Progression project, a JISC-funded Regional Pilot. The recent Pedagogy and Metadata SIG meeting had provided Ben with some feedback on his work, and the aim of our meeting was to pool our efforts with a view to publishing a schema for review within the next two weeks.

Schema Elements

Julie's prospectus survey had revealed differences in the level of standardisation discernable within online course descriptions. Some institutions provided rich description of their offerings in terms of a standard template; others had some common metadata but the format and structure of additional information varied considerably. Smaller FE institutions tended to be more tightly structured. Larger, multi-site, multi-culture HE institutions often had varying information structures across (and sometimes within) their sites and faculties. We concluded from these trends that the XML schema must be capable of expressing more or less detail according to organisational need.

Full results from the survey will be published soon. Initial analysis has confirmed that the set of XML elements that had emerged through consultation and investigation seemed capable of expressing and capturing most of the structure of online course descriptions currently available in the UK. Leaving aside typical metadata such as identifiers, codes, titles and types, the elements that seemed to capture recurrent sections within course and/or module descriptions were:
<accreditation />
<award />
<adjustment />
<admission />
<aim />
<assessment />
<benchmark />
<career />
<contact />
<facilities />
<finance />
<objective />
<opportunity />
<outcome />
<quality />
<rationale />
<regulations />
<resource />
<specialFeature />
<structure />
<support />
<syllabus />
<teachingAndLearning />
<teachingBody />
During the survey it became apparent that an additional <profile /> element would be required to hold profiles of past (or present) students, and this was consequently added to the list.

For the purposes of the draft schema, we concluded that maximum flexibility would be achieved by regarding these elements as concrete substitutions for an abstract "section" that can be repeated many times. In other words, a course description has many sections, each outlining different aspects of the course. This approach would be similar to the dublin core metadata schema: metadata elements such as <dc:title /> and <dc:type /> are substituted for an abstract <dc:any /> element. After detailed discussion we concluded that the abstract "section" element should be capable of holding simple text or complex content, particularly XHTML (to allow institutions to hold formatted information if required) and it must also carry an "id" element to facilitate cross-referencing.

Discussions about quality assurance practice and Programme Specification documents identifed candidate elements for additional structure:

Schema Structure

To reflect the broad domain for which the schema is being developed, and its planned role within the e-Framework Curriculum Service, we decided that the root node for the schema should be <Curriculum>.

Within <Curriculum> detail could then be supplied for organizations (<org>) referenced as teachingBody, awardingBody, accreditingBody ... etc, and curriculum components. After considerable debate over several months we confirmed our decision that a neutral term was required that could be used for Programmes, Courses, Units, Modules, Stages, Lesson Plans or whatever curriculum component was being described. The generic <component> element could then be typed as required to indicate that it was defining a Course.

Analysis of Programme Specifications from several institutions revealed a recursive relationship between curriculum components. A component might have many subcomponents: for instance, many units might be associated with a course. Typically a superset of possibilities would be specified along with rules or constraints that determine valid combinations. In some cases, subcomponents are described inline within the parent document: for instance, a course document might have detailed descriptions of the stages of which it is comprised. In other cases, references to subcomponents are given: for instance, a list of module codes is given along with an appendix of module descriptions. We therefore concluded that valid child elements of a <component> should include <component> and <componentRef>.

Our final area of structural debate concerned the relationship between a component specification and offerings of that component. An approved course specification might be offered at different times, in different places, in different modes. Whilst the course specification might contain general statements about the pattern of offerings for which approval was being sought, distinct offerings would specify time, place, mode. In other words, an offering realizes a component specification, and a component might be realized by multiple offerings. For purposes of marketing and enrolment, offerings, rather than components, need to be advertised. Prospective students need to see the approved description of the component plus details of offerings currently available. As XML does not have an in-built concept of inheritance and specialisation for element content, this need must be handled programmatically, perhaps by specifying a relationship between and , and making offering capable of expressing all component content plus specific details of when, where and how this particular instance is offered. This and other possibilities will be considered further as the XSD takes shape.