1EdTech Content Packaging Specification Primer
|
Date Issued: |
01 March 2007 |
Latest Version: |
|
Supersedes: |
1EdTech Content Packaging Specification Primer v1.2 Internal Draft v2.0 |
Comments / Feedback: |
http://www.imsglobal.org/community/forum/categories.cfm?catid=92 |
|
|
IPR and Distribution Notices Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation. 1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf. Copyright © 2007 1EdTech Consortium. All Rights Reserved. Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals. Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/license.html. The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns. THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION. |
Intellectual property acknowledgements
“UML,” is either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries.
“W3C,” “HTTP” and “XML” are registered trademarks or trademarks of the World Wide Web Consortium; marks of W3C are registered and held by its host institutions MIT, ERCIM, and Keio.
“XML,” “HTML,” “XHTML” are trademarks of the W3C; marks of W3C are registered and held by its host institutions MIT, ERCIM, and Keio.
“SCORM” is a registered trademark of the Advanced Distributed Learning Initiative, Office of the Deputy Under Secretary of Defense (Readiness), Readiness and Training, 1E525, 4000 Defense Pentagon, Washington, D.C. 20301.
This primer provides a basic introduction to the 1EdTech Content Packaging Specification. The 1EdTech Content Packaging specification describes data structures that can be used to exchange data between systems that wish to import, export, aggregate, and disaggregate packages of content. 1EdTech content packages enable exporting content from one learning content management system or digital repository and importing it into another while retaining information describing the media in the content package and how it is structured, such as a table of contents or which web page to show first. The 1EdTech Content Packaging Specification focuses on the packaging and transport of resources but doesn’t determine the nature of those resources. This is because the specification allows adopters to gather, structure, and aggregate content in an unlimited variety of formats.
Intellectual property acknowledgements 2
1.1 Context for the 1EdTech Content Packaging Specification 5
1.2 Overview of the 1EdTech Content Packaging Specification 5
1.3 Structure of this document 6
3. Acronyms and abbreviations 8
4. Content packages and content packaging 9
5. The historic perspective 10
5.2 A summary of changes from version 1.1 10
6.1 Packaging learning material 11
6.2.1 The simple stand-alone package 12
6.2.3 The composite or meta-package 12
6.3 Creating an application profile of a content package 13
7.1.4 Best Practice and Implementation Guide 14
7.2 The XSD, vocabularies, and examples 15
1.1 Context for the 1EdTech Content Packaging Specification
People want to share e-learning content for a variety of reasons. Educators may want to share useful lessons with colleagues, publishers want to sell content, and communities of practice want to pool resources to reduce the costs of creating effective learning content. All of these scenarios presuppose that content can be exchanged freely without technical barriers.
In addition, it is desirable to have a variety of tools to help with the creation, management, and playback of e-learning content. Different people may have different requirements for each of these types of tools. For example, price may be more important than user-friendliness for some. What’s more, such requirements may change over time, which means that the same content should work with tools that may not have been developed yet.
To enable sharing of content and to give people a choice of content creation, management, and playback tools, it is necessary to agree on a content format. Such a format means that, for example, content can be authored without worrying about which learning content management system (LCMS) will be used at any given point in a content object’s lifetime.
1EdTech Content Packaging is such a content format agreement.
1.2 Overview of the 1EdTech Content Packaging Specification
1EdTech Content Packaging describes data structures that can be used to exchange data between systems that wish to import, export, aggregate, and disaggregate packages of content. The specification enables exporting content from one LMS or digital repository and importing it into another while retaining information that describes the media in the 1EdTech content package and how it is structured, such as a table of contents or which HTML page to show first.
The 1EdTech Content Packaging Specification focuses on the packaging and transport of resources, but doesn’t determine the nature of those resources. The specification allows adopters to gather, structure, and aggregate content in an unlimited variety of formats. A typical content package consists of Web pages and common picture formats, such as JPEGs. Other packages may contain more specialized material such as Java applets or other 1EdTech formats, such as Question and Test Interoperability items or 1EdTech Learner Information Packaging fragments. However, using such resources requires specialized tools beyond an LMS that implements just an 1EdTech content package.
The central part of a content package is the manifest. A manifest describes the logical package and the relationships among all of its components. The manifest is both an XML document, and, more abstractly, the structural information in that document. Within the manifest, the resources section functions as a bill of materials. It lists all files that are contained in the interchange package and all references to resources that reside elsewhere. In certain cases, it may also contain specialized structural content in the resources section of the manifest document itself. Finally, the organization section of the manifest structures all of the content package’s components into a piece of educational content.
Prior to the current work, 1EdTech Content Packaging version 1.1 was the most recent major functional revision, completed in April 2001. Since then, many requests have been made for mostly minor functional additions and corrections, resulting in the version 1.1.x series of this specification. Requests for a few major additions were allowed to accumulate as practice matured around implementing 1EdTech Content Packaging.
The documentation set for 1EdTech Content Packaging can appear to be daunting. However, a few simple guidelines make it relatively easy for even a newcomer to work through the documents:
a) Start with the primer (this document).
b) Read the 1EdTech Content Packaging Best Practice and Implementation Guide [CP, 07c] before attempting to work through either the Information Model [CP, 07a] or the XML Binding [CP, 07b].
c) Once the set of examples in the Best Practice Guide has been digested, work through the Information Model.
d) Finally, work through the XML Binding. (Often, only the implementation/engineering team needs to understand the details of this document.)
1.3 Structure of this document
The structure of the rest of this document is:
1EdTech Content Packaging Information Model v1.2 Public Draft v2.0, C.Smythe, B.Nielsen, 1EdTech GLC, Inc., March 2007. http://www.imsglobal.org/content/packaging/ |
|
1EdTech Content Packaging XML Binding v1.2 Public Draft 2.0, C.Smythe, B.Nielsen, 1EdTech GLC, Inc., March 2007. http://www.imsglobal.org/content/packaging/ |
|
1EdTech Content Packaging Best Practice and Implementation Guide v1.2 Public Draft 2.0, C.Smythe, B.Nielsen, 1EdTech GLC, Inc., 2007. http://www.imsglobal.org/content/packaging/ |
|
[SDN07, 06] |
UML Profile for Platform Independent Model Descriptions of Specifications, SDN-07, C.Smythe, 1EdTech GLC, Inc., October 2006. |
[SDN08, 06] |
UML Profile for Platform Specific Model Descriptions of Specification Bindings, SDN-08, C.Smythe, 1EdTech GLC, Inc., October 2006. |
[SDN11, 06] |
Vocabulary Definitions, Registration and Maintenance Procedures, SDN-11, C.Smythe, 1EdTech GLC, Inc., July 2006. |
1EdTech Vocabulary Definition Exchange Information Model v1.0, A.Cooper, 1EdTech GLC, Inc., February 2004. http://www.imsglobal.org/vdex/ |
HTML |
Hypertext Mark-up Language |
Institute of Electrical and Electronics Engineers |
|
Organization for Standardization |
|
JPEG |
Joint Picture Encoding Group |
LCMS |
Learning Content Management System |
Learning Management System |
|
PIM |
Platform Independent Model |
PSM |
Platform Specific Model |
Sharable Content Object Reference Model |
|
SDN |
Specification Development Note |
UML |
Unified Modelling Language |
Vocabulary Definition Exchange |
|
World-wide Web Consortium |
|
Extensible Mark-up Language |
|
4. Content packages and content packaging
Functionally, 1EdTech Content Packaging sits between the authoring and playback of basic components, such as HTML pages, and the content management processes of a digital repository or LCMS. For that reason, the heart of 1EdTech Content Packaging consists of a few related, fundamental, content-aggregation concepts. These concepts capture the need to scope, gather, describe, list, and structure the components that make up a content package.
At the top of the aggregation tree, the logical package includes all the components of the content package, regardless of whether they are local or remote, or whether they are referred to directly or indirectly. In other words, the logical package defines the scope of a content package.
Next is the interchange package, which is the collection of components (i.e., files, at this level) that can be exchanged. The form (e.g., ZIP, CD–ROM, etc.) is not defined, but an interchange package needs to have some type of file-system representation. This is typically a ZIP archive, but a CD–ROM or a folder on a network drive is also possible. The interchange package can, but doesn’t have to, physically contain all of the components scoped by the logical package.
The central part of the content package is the manifest. The manifest describes the logical package and the relationships among all of its components. The manifest is both an XML document, and, more abstractly, the structural information in that document.
Within the manifest, the resources section functions as a bill of materials. It lists all the files that are contained in the interchange package and all references to resources that reside elsewhere. In certain cases, it may also contain specialized structural content in the resources section of the manifest document itself.
Finally, the organization section of the manifest structures all of the logical package’s components into a piece of educational content. The organization section describes the static relationships between the different resources, and can also contain instructions for dynamic and interactive learning activities.
Prior to the current work, 1EdTech Content Packaging version 1.1 was the most recent major functional revision, completed in April 2001. Since then, requests have been made for mostly minor functional additions and corrections, resulting in the version 1.1.x series of this specification. Requests for a few major additions were allowed to accumulate as practice matured around implementing 1EdTech Content Packaging.
5.2 A summary of changes from version 1.1
Major functional changes from version 1.1 up to and including 1.1.4 consist of:
• Separation of control documents (XSDs) from the Information Model document.
• Clarifications of the use of child manifests;
• ‘xml:’ prefix recommendation – adoption of the W3C ‘xml.xsd’ file for the definition of the ‘xml:’ name-spaced attributes available to the content package. This makes newer packages easier to validate with modern tools.
• parameter attribute vocabulary – adoption of a syntax for the definition of parameters as contained in the parameter attribute plus definition of the algorithm to construct an associated URI.
• Href filename format recommendation – formal definition of the file name formats that must be adopted when using the Href attribute.
• ZIP file format recommendation – formal definition of the ZIP file format that shall be adopted for interchange packages that are ZIP archive based.
• Name-spacing of xml:lang made consistent.
• Clarification of the scoping of meta-data in a content package.
• Clarified the usage of local and remote XSDs for instance validation.
• Improved guidance on merging submanifests. This is an intricate operation that may be best replicated using the newer ipointer mechanism.
• Clarified submanifest referencing using the <dependency> element.
• Requirement to declare all files in a content package’s manifest.
In addition, the various versions contain many more clarifications and some corrections. Apart from a completely new documentation set, the main functional changes from version 1.1.4 and 1.2 are:
• Bringing the Binding into line with the Information Model such that the schema and schemaversion elements can only refer to the whole package.
• New mechanism to extend and register resource type values.
• New mechanism to extend and register organization type values.
• The <variant> element to enable package authors to point to alternative resources.
• New mechanism to refer to remote manifest structures and include them in the base manifest.
6.1 Packaging learning material
Version 1.2 (this version) of the widely adopted 1EdTech Content Packaging Specification clarifies and regularizes the behavior of software components that are engaged in the creation of 1EdTech content packages and harvesting the information contained within them. These software components are generally referred to as package writers and package readers.
The information held in 1EdTech content packages is often stored in enterprise-scale repositories. A high degree of interest exists in re-using information objects as well as their order and sequence. This kind of re-usability can leverage proven structures, apply known information in novel ways, or simply lower costs of knowledge and skill acquisition.
Earlier versions of the 1EdTech Content Packaging Specification focused almost exclusively on exchanging physical files, especially a special–purpose, compressed, binary file called a package interchange file. This version continues to support that approach, but also broadens the exchange of information to exchanging a logical package rather than a physical one. That is, an 1EdTech manifest only may be exchanged – all assets referenced within it (or other 1EdTech manifests to which it might be linked) remain in their known storage locations and are used from those systems. Logical packages dramatically reduce costs for all parties concerned in terms of storage, maintenance, and payload pushed “across the wire.” This, in turn, should greatly facilitate and accelerate the provision of information to areas in which it is best applied.
An interest is also growing in tailoring the presentation of information to a given profile, needs, or requirements of a given individual or groups of individuals. This often involves wide varieties of the same information expressed in different formats or presentation modalities. Version 1.2 makes it possible to relate assets that support such varied and richly adaptable requirements. The approach relies heavily on an emerging consensus around how best to define such requirements and describe the assets enabling them in meta-data.
Meta-data is key to the discovery and use of information expressed in terms of references to physical artifacts, both digital and non-digital. Version 1.2 heals a long-running issue in terms of its approach to modelling meta-data and binding the data structures used to convey it. 1EdTech Content Packaging v1.1.3 and v1.1.4 both defined specific object models for expressing meta-data, which unfortunately were not faithfully bound as data structures. This split between the definition in the Information Model and the model’s realization in XML Schema data structures has caused some confusion among adopters of 1EdTech Content Packaging.
Version 1.2 addresses this issue by declaring the original meaning normative, and the laxity of the previous bindings tolerated (i.e., the binding allows the use of schema and schemaversion to indicate meta-data control files, even if developers should not author packages in this way.)
Stability is also important for a key specification, such as 1EdTech Content Packaging. The version 1.2 project group went to some effort to provide for the future growth and adaptability of 1EdTech Content Packaging to emerging or yet-to-be-defined needs of adopters, while preserving the flexible framework that is an 1EdTech manifest. The team has accomplished this by separating the lists of vocabulary terms used by certain object classes in the Information Model from the model itself. These terms are defined and approved in a separate maintenance process that does not require a revision of the specification just to accommodate new terms.
Similarly, given the widespread adoption of 1EdTech Content Packaging and the proliferation of hundreds of thousands of 1EdTech content packages, it is important that existing software components continue to process content packages they were designed to handle and that new software components conforming to version 1.2 also process the older content packages as designed. Newer systems will also honor the new extension object classes that enable the linking and referencing behaviors desired by enterprise scale users. The new classes are defined in a separate namespace that leverages the extension points and semantics of 1EdTech Content Packaging without affecting the existing 1EdTech Content Packaging namespace. The best of the past is preserved as it provides a strong foundation for future growth without having to alter its structural integrity.
Throughout the development process, the project group has expended effort to use proven technologies defined by trusted organizations such as the World Wide Web Consortium (W3C), the Institute of Electrical and Electronics Engineers (IEEE) Learning Technologies Standards Committee, and the International Organization for Standardization (ISO), among several others. The team hopes that by adopting the technologies and vetted techniques of such organizations, 1EdTech Content Packaging will have a secure and thriving future to benefit all adopters, but most importantly, the learners for whom all this interoperability activity is focused.
As the use of 1EdTech Content Packaging has grown over the years, several general types of packages have emerged. Depending on community requirements and processes, commonly found packages tend to look like instances of one of the following stereotypes.
6.2.1 The simple stand-alone package
Using a ZIP archive for its interchange format, this package type typically includes all of its resources in the interchange file. For simplicity, it has only one level of manifest; no child manifests are included. A couple of organizations tend to be included, usually to provide an alternative to the default organization in a different language or to meet some other access requirement.
Content packages that conform with the most popular content packaging profile, the Sharable Content Object Reference Model (SCORM), also typically follow the simple stand-alone pattern. Where they differ from packages that follow other profiles is in the inclusion of meta-data. SCORM packages need to have package-level meta-data in a separate file that is linked to from the manifest. Other profiles typically include package-level meta-data inline in the manifest itself. Other differences include the support SCORM packages have for learner-to-content interaction tracking and, in SCORM 2004, 1EdTech Simple Sequencing.
Content packages of the simple, stand-alone type are likely to be most widely supported in various LMSs, and therefore, to be the most robust in interoperability.
This package type does not include all resources in the interchange file. Instead, it references them via links to a known repository. Depending on the implementation, a bare manifest package can be interchanged using either just the manifest file, or the manifest file as the sole content of a ZIP archive or other interchange file.
The advantages of using this package type include:
• The exact same resources can be re-used many times.
• Resources can be updated at any time.
• Resources can be tracked easily by the publisher or repository owner.
• Access to resources can be controlled easily and precisely by the publisher or repository owner.
The main disadvantage of this type of package is the fact that the LMS needs to have reliable access to all resource repositories.
6.2.3 The composite or meta-package
This package type takes the bare manifest type one step further by linking to other entire packages rather than just conventional resources, such as Web pages. Various patterns of aggregating packages and resources are conceivable using this package type, but it is expected that a popular pattern will be of the relatively thin package that aggregates little beyond references to a set of complete, relatively self-contained packages, similar to how a number of lectures can constitute a course.
The main advantage of the composite package is that it takes re-usability of structured content a significant step beyond other types of packages. The disadvantage is that the functionality that enables this package type is comparatively new, which means that not every package reader will be able to support all the functionality.
This common package type is not intended for presentation to a learner. Instead, it is used to store resources and definitions of their basic structures for future use. Archive packages do not have an organization section, only a resource section.
This package type is typically used to exchange raw content files that can be turned into finished packages later.
Specialized packages do not conform to a particular common pattern, but are similar in that they are used to convey very specific types of content, often inline, in the manifest. Most of these packages are combinations of packages with content defined in other 1EdTech specification, such as ePortfolios, Question and Test Interoperability items, and Learning Design Units of Learning.
In each case, a significant part of the content that is described in the manifest is neither an external file nor a structure that conforms to Content Packaging itself. Instead, the core of these packages is the description of specific data in an XML dialect, and 1EdTech Content Packaging merely provides a convenient way of aggregating such descriptions.
6.3 Creating an application profile of a content package
Over the years, various communities have produced both excellent application profiles of 1EdTech Content Packaging and guidelines for making them. These include, respectively, 1EdTech’ own Common Cartridge and the 1EdTech Application Profile Guidelines. While communities with an interest in profiling 1EdTech Content Packaging for their own purposes are advised to consult both the 1EdTech guidelines and many others that exist on the subject, some pointers can be given here.
Profiling 1EdTech Content Packaging version 1.2 has essentially two dimensions: one is the limitation of multiplicity in the specification; another is the addition of specialized structures at one of the specification’s many extension points.
The first dimension can also be called proper profiling in that it commits developers to fewer choices than the full specification allows. Common examples include the proscription of child manifests and the prescription of a particular meta-data schema.
The extension of 1EdTech Content Packaging is possible at virtually any level of the logical package. In the case of extensions to the organization section, both the existing structure can be extended (as SCORM does) and an organization can be replaced by a wholly different type of structure, such as an ISO TopicMap. In the latter case, it is advisable to provide a conventional organization alongside the alternative structure in order to ensure maximum interoperability with minimal semantic loss. People are also encouraged to submit alternative organization structures to 1EdTech for registration, so that developers can easily find out about them.
Much the same goes for extensions to the resources section of the manifest. These extensions are not usually outright replacements for the structures that 1EdTech Content Packaging itself provides, but more specific types of data that are aggregated by packages. Examples include Learner Information Profile documents and 1EdTech Question and Test Interoperability items that are included inline. It is vitally important for a package processing application (e.g., an LMS) to know about the nature of such resources in order to handle them correctly. For that reason, 1EdTech has set up a procedure to describe and submit new resource type values and flag them in the manifest.
The role of the 1EdTech Content Packaging Specification Primer (this document) is to provide a brief description of the full 1EdTech Content Packaging Specification. This is the only document that brings together all of the other documents to provide a perspective on the full specification.
The 1EdTech Content Packaging Information Model Specification [CP, 07a] is the normative description of the content package data structures and their relationships. This description uses the Unified Modelling Language (UML), and in particular, the 1EdTech UML Profile Platform Independent Model (PIM) Description for Specifications [SDN07, 06]. The Information Model document also contains conformance statements against which an implementation must comply. It also describes the core content package functionality plus the extensions that are introduced in version 2.1 (the new functionality is expressed as extensions to the core).
The 1EdTech Content Packaging XML Binding [CP, 07b] describes the realization of the Information Model in XML. The Binding document uses the 1EdTech UML Profile for Platform Specific Model (PSM) Descriptions of Specification Bindings [SDN08, 06]. This PSM has been transformed into the corresponding XML Schema Definition (XSD) files using the 1EdTech Binding Autogeneration Toolkit. The Binding is realized as two XSDs, the core content package XSD file “imscp_v1p2.xsd” and the extension functionality in the XSD file “imscp_extensionv1p2.xsd”. The Binding document describes the underlying structure of the XSD and the formats of the corresponding instances of a content package.
7.1.4 Best Practice and Implementation Guide
The 1EdTech Content Packaging Best Practice and Implementation Guide [CP, 07c] is intended to provide vendors with an overall understanding of the 1EdTech Content Packaging Specification, the relationship of the specification with other 1EdTech specifications, and a best practices guide derived from experiences of those using the specification.1 The guide also includes a several actual examples that describe how vendors can make the best use of the 1EdTech Content Packaging Specification. These examples are also useful as a starting template for each of the different forms of content packages.
The following related documents were used to support the development of this specification:
• 1EdTech GLC SDN 07: UML Profile for PIM Descriptions of Specifications [SDN07, 06] – provides the definition and description of the syntax and semantic of the UML profile used for the PIM description of the information model [CP, 07a];
• 1EdTech GLC SDN 08: UML Profile for PSM Descriptions of Specification Bindings [SDN08, 06] – provides the definition and description of the syntax and semantics of the UML profile used for the PSM description of the XML Binding [CP, 07b];
• 1EdTech GLC SDN 11: Vocabulary Definition, Registration and Maintenance Procedures [SDN11, 06] – provides the definition and description of how the ‘structure’ and resourceType’ attribute vocabularies are expressed as instances of the 1EdTech Vocabulary Definition Exchange (VDEX) specification [VDEX, 04].
7.2 The XSD, vocabularies, and examples
The written documents are accompanied by a set of XSDs and XML instances. Several XSDs are included:
• The two XSDs that are used to validate version 1.2 1EdTech content packages.
• The VDEX XSD that is used to validate the VDEX instances that contain the 1EdTech Content Packaging vocabularies.
• The IEEE Learning Object Metadata XSDs that are used to validate the meta-data contained within the vocabulary instances.
Two vocabulary files are supplied:
• imscp_structurevocabv1p0.xml – the vocabulary of the default set of types of organization structure.
• imscp_restypevocabv1.0.xml – the vocabulary of the default set of resource types.
These vocabularies are instances of the 1EdTech VDEX specification.
Finally, a set of examples is supplied. These examples, which are XML instances of a content package manifest, demonstrate all of the key features of the 1EdTech Content Packaging Specification. These instances can also be used as templates for producing other content package manifests.
The documentation set of the 1EdTech Content Packaging Specification can appear to be daunting. However, a few simple guidelines make it relatively easy for even a newcomer to work through the documents:
a) Always start with the primer (this document).
b) The 1EdTech Content Packaging Best Practices & Implementation Guide is an excellent way to understand the why, what, and how of a specification. The set of examples described in the guide is an excellent way to understand what is being created by the specification. The guide should always be read before attempting to work through either the Information Model or the XML Binding.
c) Once the set of examples has been digested, it is time to work through the Information Model. This model provides the formal definition of all of the data structures and their relationships. In most cases it is easy to spot how the data structures are realized in the examples.
d) Finally, work through the XML Binding document. Often, only the implementation/engineering team needs to understand the details of this document. This document is the definitive statement of how interoperability is achieved using XML. The Binding is formally realized as the XSD files. These files are used to validate the XML instances. (In this case those instances are the manifest files for a content package.)
the document properties
List of contributors
The following individuals contributed to the development of this document:
Name |
Organization |
Name |
Organization |
Martin Bayly |
WebCT, Canada |
Steve Hirst |
Pearson Education, USA |
Bill Bilic |
WebCT, Canada |
Scott Lewis |
ADL, USA |
Kerry Blinco |
DEST, Australia |
Wilbert Kraan |
CETIS / JISC, UK |
Jennifer Brooks |
ADL, USA |
Sheila MacNeill |
CETIS / JISC, UK |
Daniel Burgos |
UNFOLD / OUNL, NL |
Boyd Nielsen |
Independent, USA |
Adam Cooper |
Tribal Technology, UK |
Allyn Radford |
HarvestRoad, Australia |
Jan Poston Day |
Blackboard, USA |
Colin Smythe |
1EdTech, UK |
Philip Dodds |
ADL, USA |
Schawn Thropp |
ADL, USA |
Andy Heath |
Independent, UK |
Nigel Ward |
DEST, Australia |
Best Practice Guide 5, 7, 14, 15
Binding 5, 6, 7, 10, 11, 14, 15
Content Package 3, 5, 6, 9, 10, 11, 13, 14, 15
1EdTech Specifications
Content Packaging 1, 3, 5, 7, 9, 10, 11, 12, 13, 14, 15, 16, 17
Question and Test Interoperability 5, 13
Vocabulary Definition Exchange 7, 8, 14, 15
Manifest 5, 9, 10, 11, 12, 13, 15
Structure 3, 5, 6, 9, 13, 14, 15
XML 2, 5, 6, 7, 8, 9, 11, 13, 14, 15
- We recommend that new users of the 1EdTech Content Packaging Specification start with the 1EdTech Content Packaging Best Practices & Implementation Guide. The examples in this document show how we intend the specification to be used, whereas the Information Model and XML Binding documents contain the formal description of the structures, their syntax and semantics.
1EdTech Consortium, Inc. (“1EdTech GLC”) is publishing the information contained in this document (“Specification”) for purposes of scientific, experimental, and scholarly collaboration only.
1EdTech GLC makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an “As Is” and “As Available” basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
1EdTech GLC would appreciate receiving your comments and suggestions.
Please contact 1EdTech GLC through our website at http://www.imsglobal.org
Please refer to Document Name: 1EdTech Content Packaging v1.2 Primer Public Draft v2.0
Date: 1 March 2007