See: http://www.bsi.mmu.ac.uk/courses/ects_example_rgu.xml
XCRI Documents
"An XCRI-CAP XML document MUST have one of the following resources as its root element:From: http://www.xcri.org/wiki/index.php/XCRI_Course_Advertising_Profile#About
* Catalog
* Provider
* Course
In general any provider SHOULD use Catalog as the root element.
The specification allows both Provider and Course as alternative root elements to enable REST-style operations to be provided by aggregators (much in the same way that the IETF Atom specification enables both feed and entry elements to be document roots).
Resources
A resource is something that can be uniquely identified [1]. In XCRI, we identify resources using a Uniform Resource Identifier (URI). A resource can possess a number of properties, which may be simple value-strings or can be structured.
XCRI-CAP specifies the following resource classes:
* catalogs advertise providers
* providers advertise courses
* courses are presented for enrolment any number of times through presentations
* presentations instantiate courses
Inheritable property values
Some elements may be inferred from their presence in a containing resource when not present in child objects. Specifically:
- Where a presentation does not contain a venue, an Aggregator SHOULD assume that the venue details (name, address, email, fax, phone, url, image) are exactly the same as the properties of the provider. An Aggregator MAY assume that the description is the same as that of the provider.
- 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.
- Where a presentation does not contain an applyTo property, or 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 and use its contact information.
This enables XCRI documents to be less verbose by not repeating basic information"
No comments:
Post a Comment