Sam has been successful in transforming an example xml file (created from a XCRI-CAP xsd) into an SDI file for HIVE (an XML file marked-up for HIVE).
Sam is currently debugging the SDI file for validation and structure issues - in addition to making sure that the output XML file is valid for how the XCRI XML should look.
The software we are using is XMLSpy - a very useful development tool for this part of the project.
Work is continuing on refining the SDI file - in particular the issue of defining attributes for spceific elements. HIVE has a limited range of available attributes for schema elements - for example xml:lang="en-gb" is used with langstring for the title element. The problem is when XCRI refers to other attributes, for example, src / title / alt for image element or onclick attributes for x:div for description element.
Wednesday, 26 November 2008
Monday, 24 November 2008
Mapping DIVAS Validation Document Attributes to XCRI-CAP
The following is a list of the attributes/element types that QA and the project team would like HIVE to specifically record against validations (these are also considered as the searchable elements) - possible XCRI-CAP elements are hyperlinked:
- Subject (use jacs?) http://www.xcri.org/wiki/index.php/Subject
- Level eg BA Hons http://www.xcri.org/wiki/index.php/Level
- Validation Date http://www.xcri.org/wiki/index.php/Generated
- Face-2-Face or eLearning (Distance Learning) http://www.xcri.org/wiki/index.php/AttendanceMode
- Site of Delivery http://www.xcri.org/wiki/index.php/Address
- Form of Assessment http://www.xcri.org/wiki/index.php/AssessmentStrategy
- Mode of Delivery (Part Time / Full Time / Fast Track 2 year) http://www.xcri.org/wiki/index.php/StudyMode
- Faculty/School http://www.xcri.org/wiki/index.php/Address
- Award Title http://www.xcri.org/wiki/index.php/Title
- Prof Body Associated http://www.xcri.org/wiki/index.php/AccreditedBy
Thursday, 20 November 2008
Understanding the XML
Useful link: http://www.w3schools.com/schema/schema_elements_ref.asp
I have been comparing the HIVE SDI XML file for IMS 1.3 and the XSD file.
Interestingly - the XML (SDI) file used by HIVE does not reference the LOM 1.3 XSD URL - however this does appear in the exported metadata XML - see:
HIVE must have this recorded somewhere else.
This is useful to know - as I am writing (attempting to write) an SDI file (XML) for XCRI-CAP. This is a bit trickier than the LOM example as LOM is neatly linear elements (hierarchical tree - see image)
XCRI - is somewhat less linear and object led - so writing out a structured tree for it may require some interrogation to identify elements and the branches/leaves. Essentially I need to write nested tags with attributes that tell HIVE how to provide the GUI/Boxes for the data inputer.
I have been comparing the HIVE SDI XML file for IMS 1.3 and the XSD file.
HIVE must have this recorded somewhere else.
This is useful to know - as I am writing (attempting to write) an SDI file (XML) for XCRI-CAP. This is a bit trickier than the LOM example as LOM is neatly linear elements (hierarchical tree - see image)
XCRI - is somewhat less linear and object led - so writing out a structured tree for it may require some interrogation to identify elements and the branches/leaves. Essentially I need to write nested tags with attributes that tell HIVE how to provide the GUI/Boxes for the data inputer.
Exploring the XCRI Markup
See: http://wiki.teria.no/confluence/display/CIF/xcri-properties
See: http://www.bsi.mmu.ac.uk/courses/ects_example_rgu.xml
XCRI Documents
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"
Wednesday, 19 November 2008
Creating a XCRI-CAP GUI for HIVE
I have been interrogating the xml (SDI file) for the current IMS schema in HIVE.
In simple terms, the XML file appears to be a modified file, which is marked up against the HIVE syntax/markup - this markup outlines not only the schema hierarchy tree elements but also how they are presented to the metadata inputer.
Tuesday, 18 November 2008
XCRI-CAP & HIVE
If and when we decide to use XCRI-CAP as the metadata schema for HIVE (and this is not certain) we will have to 'configure' HIVE to accept this schema. This may be a simple process, but will require 'defining' the schema through creating an SDI file, which also assists in generating the GUI interface.
From HIVE admin guide:
From HIVE admin guide:
"Chapter 3: Creating an SDI File
Hive imports, exports and stores metadata in XML format.
Standards bodies such as IMS, SCORM, and Learning Federation express the format of the metadata using an XML schema file. The actual metadata is stored in an XML instance file that can be validated against the schema file.
When a Hive user opens the Edit Metadata dialog, Hive dynamically generates a user interface into which the metadata is entered. From the user’s perspective, the format of the dialog closely matches the metadata format as published by the standards body.
As published by the standards body, the metadata XML schema file does not contain all of the information needed to generate the user interface. This extra information must be placed into a Structure Definition Instance (SDI) file. The SDI file is an XML instance file.
The SDI file contains:
- Titles and descriptions of data items that are displayed on the GUI.
- The type of field into which the data must be entered, for example, a single-line text entry field or date field.
- The maximum number of characters that can be entered into a field.
- Information that specifies whether the field is mandatory or optional.
- Information that specifies whether multiple versions of the field are allowed."
Subscribe to:
Posts (Atom)