Status

This specification has been reviewed by members of the XCRI community and has been endorsed by the XCRI Project Team. It is a stable document and may be used as reference material or cited from another document. If there are any significant issues with this document other than minor typographical or grammatical corrections, it will not be modified, but instead a new version issued with a new version number.

Patents

This specification is subject to a royalty free patent policy.

There are no known patents covering any of this work. If you think that part of this work may be subject to an existing or pending patent, please email the editors.

Copyright and License

This work is (c) 2005-2011 the University of Bolton, and licensed under a Creative Commons Attribution 3.0 Licence. All contributions MUST be licensed under the same conditions. This is to ensure that the specification work can be transferred to an appropriate standardisation body.

Inspiration and acknowledgements

The development of this specification has benefited from close co-operation with the CEN Workshop on Learning Technologies and the Rome Student Systems and Standards Group (RS3G). We would also like to thank the many UK institutions and lifelong learning networks that have contributed to its development through their work on implementation. We also thank JISC for supporting the development of this specification. In particular we would like to acknowledge the contributions of Simon Grant, Tavis Reddick, Ben Ryan, Stuart Feltham, Liam Green-Hughes, Martin Edney, Richard Hyett and all the others who have contributed to the specification through the XCRI community.

Introduction

The XCRI Course Advertising Profile (XCRI-CAP) is a specification to enable the interoperability of descriptions of courses, or any other kind of learning opportunity, between the course provider and any number of Aggregators and brokers, by supplying an XML description.

XCRI-CAP 1.2 provides an XML format based on the CEN Metadata for Learning Opportunities standard (see [EN 15982]), which means documents that conform to this specification have the same underlying semantics as those produced to other bindings of the same standard.

An XCRI-CAP document typically consists of a top-level <catalog> element, encapsulating a single <provider>, and a collection of <course> descriptions for the courses offered by the provider. Each course has various descriptive information available such as syllabus, the qualification you can obtain, career options and so on. The course is also divided into any number of <presentation>s, which are the 'instances' or 'offerings' of the course that a prospective student will apply for, and which have specific start and end dates, locations and so on, and can vary in aspects such as the location and mode of study (e.g. a full-time and part-time presentation, with different duration and start date).

The following diagram illustrates the main elements of the specification.

Conformance

There are two classes of application that can conform to this specification:

A Producer is a class of application that produces XCRI-CAP documents

An Aggregator is a class of application that aggregates XCRI-CAP documents

A product MAY belong to both classes.

A strictly conforming instance is a set of structured information constituted only of elements and attributes defined by this standard and fully qualified refinements of the elements
defined in this standard.

A fully qualified refinement is defined for the purpose of conformance as an element that explicitly extends an
element defined by this standard. A fully qualified refinement MUST be capable of being processed according
to the semantics of the element it extends.

A conforming instance MAY contain additional elements and attributes not defined by this standard.

A conforming Producer MUST be capable of generating and sharing strictly conforming instances.

A conforming Aggregator MUST be capable of processing strictly conforming instances.

XCRI Documents

A Producer MUST create XCRI-CAP documents that are valid XML documents.

A Producer MUST create XCRI-CAP documents with one of the following elements as its top-level element:

catalog

provider

course

An Aggregator MUST be able to process a valid XCRI-CAP document.

GuidelinesA Producer SHOULD use the catalog element as the top-level element for general purpose use. The specification allows both provider and course as alternative top-level elements to enable REST-style operations to be supported.

Core Elements

the <catalog> element

NoteThe catalog element does not imply a relationship between the XCRI-CAP document and a course catalog. A catalog does not necessarily relate to a concept of a catalog in an originating or consuming system, but rather provides the context for the content of the XCRI-CAP document.

Attributes:

@generated (required) The date and time at which the catalog was generated, in [ISO 8601] format.

Elements:

all Common Elements

provider (optional, multiple) The provider whose courses are included in the catalog.

Producers MUST include a @generated attribute, and the value of the attribute MUST be a valid date/time according to [ISO 8601].

Guidelines

generated: Producers SHOULD use both date and time in the @generated attribute. Example: '2010-08-02T06:14:37Z'.

generated attribute is missing: If a <catalog> does not contain an @generated attribute, then an Aggregator MAY process the document treating the document as if it was generated at the time the catalog was obtained by the Aggregator.

generated attribute is invalid: if the value of the @generated attribute is not a valid date/time according to ISO 8601, then an Aggregator SHOULD treat the XCRI document as being in error.

Identifiers: Producers SHOULD create Provider elements with a default unique identifier formatted as a URL (e.g. "http://www.bolton.ac.uk/"). Producers MAY include additional identifiers in other formats, but these SHOULD be qualified using xsi:type to a specific identifier namespace. An example would include the UK provider reference number (UKPRN) within the UKRLP:UKPRN namespace. See the identifier element definition for more details.

Title: Producers SHOULD include at least one title element for a provider, which SHOULD be the trading name of the organisation

Type: Where a Producer uses the Type element for a provider, this SHOULD use a sector-specific controlled list of terms for this element. These SHOULD be qualified using xsi:type to a specific vocabulary namespace.

Url: Producers SHOULD include one Url element for each provider, which SHOULD include a URL for its homepage, or its applications microsite, in addition to its primary domain identifier (see above).

Course: In almost all cases Producers SHOULD include at least one course for a provider. The capability for supporting zero courses is offered for cases where XCRI CAP is used to format course search results.

Identifier: A Course SHOULD have a unique identifier formatted as a URI (e.g. "http://www.bolton.ac.uk/courses/1"). Additional identifiers in other formats may be used, but SHOULD be qualified using xsi:type to a specific identifier namespace. See the guidance on the identifier element for more details.

Title: Producers SHOULD include at least one title element for each course.

Subject: Producer SHOULD include at least one subject element for each course. See the guidance on the subject element for more information.

Level: This is included for compatibility with [EN 15982]. Producers SHOULD NOT use this element, and Aggregators SHOULD make use of the Qualification and Credit elements to assist users to discover courses by level.

Credit: Producers SHOULD use separate credit elements for describing the credits available under each scheme, for example CATS or ECTS.

Absence of Image: Where a course does not contain an image, but its containing provider does, an Aggregator MAY use the image of the provider when displaying the course.

the <presentation> element

A presentation is a particular instance of the course offered at a specific time and place or through specified media. It is the entity to which learners apply. Alternative names for this type of structure include course offering and course instance.

Absence of study mode and attendance: Aggregators SHOULD assume that the default value for studyMode is "Full Time", the default for attendanceMode is "Campus", and the default for attendancePattern is "Daytime"

Start dates : A Producer SHOULD include a start element even if there is no specific start date as this can still be used to describe the start details- see the section on Temporal Elements.

Duration: A Producer SHOULD include a duration element or start and end dates, or both.

Absence of Image: Where a presentation does not contain an image, but its containing course does, an Aggregator MAY use the image of the course when displaying the presentation.

Absence of Title: Where a presentation does not contain a title, but its containing course does, an Aggregator MAY use the title of the course when displaying the presentation.

Absence of Description: Where a presentation does not contain a description, but its containing course does, an Aggregator MAY use the description of the course when displaying the presentation.

Common Elements

Each of the core elements of XCRI use the following set of common elements:

the <identifier> element

An unambiguous reference to the resource within a given context. See [EN 15982] and [ISO 15836].

Structures MUST NOT contain more than one identifier without an explicitly-defined encoding scheme, and this MUST be A Uniform Resource Identifier (URI) conforming to the URL scheme as specified by IETF RFC 3986.

GuidelinesIdentifier:: Where a subject has both a human-readable label and an identifier, Producers SHOULD use an @identifier attribute of the subject element for the identifier, and the text content of the subject element for the label.

Localisation: Producers SHOULD use an xml:lang attribute to provide alternative language versions of a subject element.

Vocabularies: Producers SHOULD use vocabulary encoding schemes to include classification terms using the subject element.

Inheritance: This element and any refinements of it is inheritable. See the section on inheritance for more guidance.

the <type> element

Guidelines
Producers MAY use this element to classify providers, courses, qualifications and presentations; additional guidance may be found under the sections on the Provider, Course, Qualification and Presentation elements.

When to use Url versus Identifier: Producers SHOULD Use identifier with the default encoding type in addition to the url element wherever possible. Also, Producers SHOULD use this element when the resource cannot be given a dereferencable URL as an identifier (for example, a course description generated from within a CMS, or where the identifier is a URN or HDL) to indicate a place on the provider's website where further information can be obtained, even if it is just general information about the department offering the course.

Image format: A Producer SHOULD offer images in standard formats, such as PNG and JPEG.

Accessibility: While @alt is optional, following the structure of XHTML, a Producer SHOULD provide meaningful alternative text.

Inheritance: This element and any refinements of it is inheritable. See the section on inheritance for more guidance.

Common Descriptive Elements

abstract (optional, multiple, inheritable)

applicationProcedure (optional, multiple, inheritable)

assessment (optional, multiple, inheritable)

learningOutcome (optional, multiple, inheritable)

objective (optional, multiple, inheritable)

prerequisite (optional, multiple, inheritable)

regulations (optional, multiple, inheritable)

Guidelines The <course> and <presentation> elements MAY use any of the Common Descriptive Elements. See the course and presentation element definitions for guidelines on usage in each specific context.

GuidelinesRefinements: Producers MAY refine the address element using other schemes to create specific address components. If using an alternative or additional encoding scheme, the scheme SHOULD be indicated using an xsi:type attribute.

Document order: Aggregators SHOULD interpret any untyped address elements in document order by default.

PO Boxes Producers MAY use an address element for PO Box information.

Note Attention is drawn to UPU-S42, EN14142-1 and GEO-RSS for alternative content for this element

identifier: It is possible that Awarding Bodies will have permanent URLs for the qualifications they award; these would be preferable identifiers, but it is accepted that they may be difficult to collect, so internal identifiers are a practical alternative. Producers SHOULD also include an identifier that refines this property where possible to refer to an entry in a specific qualification framework, e.g. QAN.

educationLevel: Producers SHOULD where possible use a URI to refer to a level within a relevant framework, e.g. "http://purl.org/net/cm/terms/EQF#4" would refer to EQF level 4. Attention is drawn to [1]

awardedBy and accreditedBy: A Producer SHOULD use the common name of the organisation for the content of these elements.

absence of awardedBy or accreditedBy: Where a qualification does not contain an awardedBy and/or accreditedBy property, an Aggregator SHOULD interpret this as meaning the capability is provided by the Provider.

Note

In earlier versions of XCRI the AwardedBy and AccreditedBy elements were organisation structures. However in XCRI-CAP 1.2 we define these purely as literal values, based on actual usage by implementations.

the <credit> element

An account of the credits that can be obtained from completion of a course. See [EN 15982]

Note Attention is drawn to [CWA16077] for the definition of the following elements and for additional guidance on their use

Elements:

scheme (optional, but see Guidelines) The scheme under which credits are obtained. See [CWA16077]

level (required) The level at which credits are obtained. See [CWA16077]

value (required) The number of credits that can be obtained. See [CWA16077]

If the <credit> element does not contain a <level> or <value> child element, Aggregators MUST treat the <credit> element as being in error.

If the <credit> element does not contain a <scheme> child element, and no default value has been agreed between the Aggregator and the Producer, then the Aggregator MUST treat the <credit> element as being in error.

If the <credit> element contains more than one <scheme> child element, Aggregators MUST treat the <credit> element as being in error.

the <duration> element

@interval (optional). A machine-readable interval formatted as an [ISO 8601] duration-only time interval.

If the <duration> element has no text content, the <duration> element is in error and an Aggregator MUST ignore this element.

If the <duration> element contains both text content and an @interval attribute, and the value of the @interval attribute is NOT a duration-only time interval as specified by [ISO 8601], then an Aggregator MUST process the text content and ignore the interval attribute.

GuidelinesUse of the interval attribute While the text content of the duration element is intended to contain a human-readable description of the duration of the learning opportunity, the interval attribute can be used to provide a machine-readable equivalent. If there is no direct machine-equivalent value (e.g., the duration is flexible), then Producers SHOULD NOT include the interval attribute.

If the value of x is greater than the value of y, Aggregators MUST treat this element as in error and ignore this element.

If the content of this element is not one of the values or patterns defined above, Aggregators MUST treat this element as in error and ignore this element.

Examples:

14+
14-16
14-19
any

Guidelines

If the value of y is greater than or equal to 99, Aggregator MAY treat the value of this element as being equivalent to x+.

If the value of x or y is greater than 120, Aggregators MAY either truncate the value from the right to a more realistic number, for example changing "124" to "12", or they MAY treat this element as in error and ignore this element.

GuidelinesProvider: Producers SHOULD use the provider element to describe the organisation which acts as the provider of the venue. This MAY be a sub-organisation of the provider of the presentation (such as a department or school), or it MAY be a third party or external organisation.

Provider Properties: When a provider element is used in a venue element, Producers SHOULD include only basic information about an organisation, such as identifier, title, description, url, image and location.

Location: When a provider element is used in a venue element, Producers SHOULD include a location element.

Processing XCRI CAP XML Documents

Temporal Elements

A Temporal Element contains information about dates and times, and this can include both the "human readable" and the "machine processable" aspects of information.

A Temporal Element is defined as having the following attributes:

@dtf (optional) A machine-processable date or time

A Temporal Element MUST contain temporal information suitable for presentation as text content.

Note For example "September, 2012" or "Early Summer, 2011".

If a Temporal Element contains a @dtf attribute, this attribute MUST contain a date or time formatted in accordance with [W3C-DTF], as used in the definition of the [W3C XML Schema] specification's "DateTime" type OR "Date" types, at any level of precision.

Note For example, the year only, or year-month-day

If a Temporal Element does not contain text content, an Aggregator MUST treat the element as in error and ignore the element.

If a Temporal Element has a @dtf attribute, and the value of the attribute does not contain a valid date or time according to [W3C-DTF], an Aggregator MUST treat the element as in error and ignore the element.

Descriptive Text Elements

A Descriptive Text Element is defined as having the following attributes:

@lang (optional) The language used for the description

@href (optional) A link to supporting information

The content of a Descriptive Text Element MUST be one of either:

Empty

Plain unescaped text content

Valid XHTML 1.0 content

If a Descriptive Text Element has an @href attribute, the Producer MUST NOT include any text content or child elements.

If a Descriptive Text Element has an @href attribute and the <description> element contains either text content or child elements, an Aggregator MUST treat the element as in error and ignore the element.

Example

<dc:description>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>This module shows how to take an existing presentation and modify it and how to create
your own presentations. No knowledge of PowerPoint is assumed.</p>
<p>The topics covered are:
<ul>
<li>Using and modifying an existing PowerPoint presentation</li>
<li>Creating a simple presentation</li>
<li>Making use of themes and schemes supplied with PowerPoint</li>
<li>The PowerPoint views</li>
<li>Printing and saving your presentation</li>
</ul>
</p>
</div>
</dc:description>

Guidelines

Encoding schemes: Use of vocabularies for types of Descriptive Text Elements is encouraged.

Use of images: Images SHOULD NOT be referenced from within the Descriptive Text Element element by Producers as these are unlikely to be presented by Aggregators; potentially an image tag can be used to execute cross-site scripting (XSS) attacks. Instead, any image SHOULD be provided separately using the XCRI image element.

XML Schema

Security Considerations

XHTML Content

This section is not normative

Descriptive Text Elements allow the delivery of XHTML. Many elements in these languages are considered 'unsafe' in that they open clients to one or more types of attack. Aggregators should carefully consider their handling of every type of element when processing incoming XHTML in XCRI CAP 1.2 Documents. Attention is drawn to the security section of RFC2854 for guidance.

Aggregators SHOULD pay particular attention to the security of the IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, and LINK elements, but other elements might also have negative security properties.

XHTML can either directly contain or indirectly reference executable content.

Conformance to [EN 15982]

This section is not normative

XCRI CAP 1.2 is a conforming binding for [EN 15982]. This means that XCRI CAP 1.2 provides a binding for all the classes and properties defined in [EN 15982] but also adds extensions. This means that any XCRI CAP 1.2 XML document is also a conforming instance of [EN 15982].

The tables below show how [EN 15982] classes and properties are related to XCRI CAP 1.2 elements.

Equivalent indicates that XCRI defines an element in its own namespace that is semantically equivalent to the [EN 15982] class or property, and can be considered a fully qualified refinement of the [EN 15982] class or property. (In most cases, the only difference is the label).

Implemented By indicates that the XCRI element is a direct implementation of the [EN 15982] class or property using the [EN 15982] namespace.

Extension indicates that the XCRI element is an extension of [EN 15982] and does not directly map onto an existing [EN 15982] property or class.

Refined By indicates that the XCRI element is a fully qualified refinement of an [EN 15982] class or property.

Mapping [EN 15982] classes to XCRI elements

[EN 15982] class

Relationship

XCRI element

Conformance Level

Learning Opportunity Specification

Equivalent

Course

Strictly Conforming

Learning Opportunity Instance

Equivalent

Presentation

Strictly Conforming

Learning Opportunity Provider

Equivalent

Provider

Strictly Conforming

Mapping [EN 15982] properties to XCRI elements

[EN 15982] property

Relationship

XCRI element

Conformance Level

contributor

Implemented By

contributor

Strictly Conforming

date

Implemented By

date

Strictly Conforming

date

Refined By

end

Strictly Conforming

date

Refined By

applyFrom

Strictly Conforming

date

Refined By

applyUntil

Strictly Conforming

description

Implemented By

description

Strictly Conforming

identifier

Implemented By

identifier

Strictly Conforming

subject

Implemented By

subject

Strictly Conforming

title

Implemented By

title

Strictly Conforming

type

Implemented By

type

Strictly Conforming

url

Implemented By

url

Strictly Conforming

hasPart

Implemented By

hasPart

Strictly Conforming

location

Implemented By

location

Strictly Conforming

offers

Equivalent

Elided by the containment of Course elements in Provider elements rather than by explicit association

Strictly Conforming

specifies

Equivalent

Elided by the containment of Presentation elements in Course elements rather than by explicit association

Strictly Conforming

qualification

Implemented By

qualification

Strictly Conforming

credit

Implemented By

credit

Strictly Conforming

level

Implemented By

level

Strictly Conforming

offeredAt

Equivalent

venue

Strictly Conforming

start

Implemented By

start

Strictly Conforming

duration

Implemented By

duration

Strictly Conforming

cost

Implemented By

cost

Strictly Conforming

language of instruction

Implemented By

languageOfInstruction

Strictly Conforming

prerequisite

Implemented By

prerequisite

Strictly Conforming

places

Implemented By

places

Strictly Conforming

engagement

Implemented By

engagement

Strictly Conforming

engagement

Refined By

studyMode

Strictly Conforming

engagement

Refined By

attendanceMode

Strictly Conforming

engagement

Refined By

attendancePattern

Strictly Conforming

objective

Implemented By

objective

Strictly Conforming

assessment

Implemented By

assessment

Strictly Conforming

N/A

Extension

languageOfAssessment

Conforming

N/A

Extension

applyTo

Conforming

N/A

Extension

image

Conforming

N/A

Extension

age

Conforming

N/A

Extension

abstract

Conforming

N/A

Extension

applicationProcedure

Conforming

N/A

Extension

learningOutcome

Conforming

N/A

Extension

regulations

Conforming

Mapping from XCRI CAP 1.2 to [EN 15982]

This section is not normative

An XCRI document is already a conforming instance of [EN 15982]. The following guidelines are intended to assist implementers in converting XCRI CAP 1.2 documents to strictly conforming instances of [EN 15982].

Equivalents

Elements identified as "equivalent" should be converted directly into their equivalent element in [EN 15982]; for example, <xcri:venue> should be converted to <mlo:offeredAt>

Refinements of <engagement>

The <studyMode>, <attendanceMode> and <attendancePattern> elements should be treated refinements of mlo:engagement when converting an document from XCRI CAP 1.2 to a strictly conforming instance of [EN 15982].

Refinements of <date>

The following elements should be treated as refinements of dc:date when converting from XCRI CAP 1.2 to a strictly conforming instance of [EN 15982]:

end

applyFrom

applyUntil

Temporal Elements

In general [EN 15982] instances would expect to have temporal elements to contain data in [W3C DTF] format; therefore when converting from XCRI CAP 1.2, you should first map the value of any @dtf attribute of these elements to the content of the dc:date element. If there is no @dtf attribute, then the text content of the XCRI element should be used.

Extensions

To convert an XCRI CAP 1.2 XML document so that it is a strictly conforming instance of [EN 15982], the following extensions should be omitted:

languageOfAssessment

applyTo

image

age

abstract

applicationProcedure

learningOutcome

regulations

Location details

While [EN 15982] does not define a detailed structure for the mlo:location element, XCRI CAP 1.2 defines a structure of address and contact information. This is still strictly conformant, but may need to be converted to make sense in other systems, either by mapping the elements to another contact information schema (e.g. PortableContacts or VCard) or downgrading to plain text content.