MMU is currently reviewing the information it collects about Programmes and the Units that comprise them with a view to streamlining curriculum design, approval and delivery. The goal is to enter data once and re-use data items where they are needed: for instance, for setting up enrolment possibilities and assessment regimes in the student records system, or advertising courses in the prospectus.

Traditionally, information about Programmes and Units has been collected in Word documents for review through Quality workflows. Recently, templates used for these Word documents have been scrutinised in an institution-wide review of the Programme Approval, Review and Modification (PARM) process. Simplified versions have been developed in consultation with colleagues from Planning and Management Information and the Centre for Quality Assurance and Enhancement.

Whilst naming conventions vary across the institution, simplified versions of the Programme and Unit documentation have been developed based on a five level hierarchy:

• Programme Specification
  (top level document scrutinised as a whole at a QA event)
  • Award Specification
    (defines the final award titles for a Programme)
    • Course Specification
      (defines the delivery modes for achieving each defined Award)
      • Stage Specification
        (defines the stages that comprise each Course and specifies the Units that comprise each Stage)
        • Unit Specification
          (defines the learning outcomes and assessment regime for a particular unit (or module) of study)

The following information has been identified as important for each level of specification (the column on the right provides a mapping to properties of the Learning Opportunity Specification class in the MLO information model):

A diagrammatic representation of this hierarchy of information appears below

MMU’s five level hierarchy can be represented using the forthcoming European Norm on Metadata for Learning Opportunities, using draft XML bindings under development to support the imminent release of the EN.

The hierarchy will be implemented using a custom XML schema that references (and refines) tweaked versions of the XML schema documents under development to support the EN:

• mloAd.xsd
• dc.xsd
• dcTerms.xsd
• credit.xsd
• qualification.xsd

A working prototype of an XML schema for modelling the MMU hierarchy using MLO-AD is available below:

• MMU curriculum schema

This schema permits representation as follows:

<mmu:programmeSpecification>
 <mmu:programmeCode></mmu:programmeCode>
 <mmu:programmeTitle></mmu:programmeTitle>
 <mmu:hasAward>
  <mmu:awardSpecification>
   <mmu:awardCode></mmu:awardCode>
   <mmu:hasCourse>
    <mmu:courseSpecification>
     <mmu:courseCode></mmu:courseCode>
     <mmu:courseUcasCode></mmu:courseUcasCode>
     <mmu:courseDescription></mmu:courseDescription>
     <mmu:courseDeliveryStart></mmu:courseDeliveryStart>
     <mmu:hasStage>
        <mmu:stageSpecification>
          <mmu:stageCode></mmu:stageCode>
          <mmu:hasUnit>
             <mmu:unitRef></mmu:unitRef>
             <mmu:unitMin></mmu:unitMin>
             <mmu:covers></mmu:covers>
          </mmu:hasUnit>
          <mmu:stageAward>
            <mmu:stageAwardTitle></mmu:stageAwardTitle>
            <mmu:stageAwardBody></mmu:stageAwardBody>
           </mmu:stageAward>
           <mmu:stageCredit>
            <mmu:stageCreditScheme></mmu:stageCreditScheme>
            <mmu:stageCreditLevel></mmu:stageCreditLevel>
            <mmu:stageCreditValue></mmu:stageCreditValue>
           </mmu:stageCredit>
           <mmu:stageLearningOutcome>
            <mmu:outcomeId></mmu:outcomeId>
            <mmu:outcomeTitle></mmu:outcomeTitle>
           </mmu:stageLearningOutcome>
          </mmu:stageSpecification>
        </mmu:hasStage>
        <mmu:courseSpecificEntryRequirements />
        <mmu:coursePlaces></mmu:coursePlaces>
        <mmu:courseDeliveryMode></mmu:courseDeliveryMode>
      </mmu:courseSpecification>
    </mmu:hasCourse>
    <mmu:finalAward>
     <mmu:finalAwardTitle></mmu:finalAwardTitle>
     <mmu:finalAwardBody></mmu:finalAwardBody>
    </mmu:finalAward>
   </mmu:awardSpecification>
  </mmu:hasAward>
  <mmu:programmeLearningOutcome>
   <mmu:outcomeId></mmu:outcomeId>
   <mmu:outcomeTitle></mmu:outcomeTitle>
  </mmu:programmeLearningOutcome>
 </mmu:programmeSpecification>

Proposals for curriculum information forms are currently out for circulation across the university, supported by some web mock-ups:

• Mock-up of a Unit Specification web form

It is hoped that this prototyping work on a MLO-compliant schema will accelerate development of the final system when requirements are signed-off.

I have been exploring the potential of the proposed new European Norm on Metadata for Learning Opportunities (MLO) for modelling proposed changes to curriculum.

The MLO work uses Dublin Core Abstract Model notions of refining properties to sub-class them.

I have been considering the use of Microsoft’s InfoPath for creating forms based on XML schema representations of MLO, which colleagues could use to enter proposed changes to curriculum: for instance, a change to assessment weighting for a particular course unit.

However, I seem to be coming un-stuck when I try to sub-class a property that has been defined using XML wildcards.

Here’s a simplified example of my problem. I have a Parent type that is defined as mixed content, with the xs:any wildcard specifying any element 0 or more times. I have a Child type that refines the parent to be non-mixed content with a single identifier element. InfoPath is able to generate a form for elements of type Child.

<xs:complexType name=”Child”>
<xs:complexContent mixed=”false”>
<xs:restriction base=”Parent”>
<xs:sequence>
<xs:element name=”identifier” type=”xs:string”/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>

<xs:element name=”root” type=”Child”/>

</xs:schema>

However, if I specify that the Child node has two elements (for instance, identifier and title), the schema validates but InfoPath cannot generate a form from the schema and returns the error:

Invalid particle derivation by restriction.
Base type : ‘{http://tempuri.org/XMLSchema.xsd}Parent’
Derived type : ‘{http://tempuri.org/XMLSchema.xsd}Child’

It appears that InfoPath regards the Child type as an invalid restriction of the Parent wildcard.

<xs:complexType name=”Child”>
<xs:complexContent mixed=”false”>
<xs:restriction base=”Parent”>
<xs:sequence>
<xs:element name=”identifier” type=”xs:string”/>
<xs:element name=”title” type=”xs:string”/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>

Am I missing something here, or is InfoPath correct in saying that a Child with two specific nodes is not a valid restriction of a Parent with 0 or more nodes?