Version 1.01 - Final Specification
|
IMS Enterprise XML Binding Specification
Version 1.01 - Final Specification |
Copyright © 1999 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Enterprise XML Binding Specification v1.01
Revision: December 1999
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.
IMS 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 IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © 1999 IMS Global Learning Consortium. All Rights Reserved.
Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html.
The limited permissions granted above are perpetual and will not be revoked by IMS 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.
INTRODUCTION
XML BASICS
ELEMENTS
This document describes the XML binding for Enterprise/Learning Management System (LMS) data interoperability. This document specifies the binding of the Enterprise/LMS interoperability data in eXtensible Markup Language (XML Version 1.0: http://www.w3.org/TR/1998/REC-xml-19980210).
There are some specific rules that have guided the creation of this XML binding document:
The Enterprise/LMS interoperability data model can be defined as a hierarchy. Hierarchical models are convenient for representing data consisting of many elements and sub-elements. XML is perfectly suited for representing hierarchical models. An XML document is a hierarchy comprised of elements that have contents and attributes.
An element is a component of a document that has been identified in a way a computer can understand. Each element has a tag name. When a tag name is shown as "<TAGNAME>", with less-than and greater-than symbols before and after the tag name, it serves as the start-tag to mark the beginning of an element. When that same tag name has a forward slash "/" added, it serves as an end-tag such as "</TAGNAME>". An element may have contents between its start and end-tags, and may have one or more attributes. When an XML element has a start and end-tag (also called an opening and closing tag) with a common name, it is considered to be "well-formed" XML. The contents of an element are placed between the start and end-tags as shown below: <TAGNAME>contents</TAGNAME>
An attribute provides additional information about an element. Attributes are a way of attaching characteristics or properties to the elements of a document. An element may have more than one attribute and are contained within the start tag of an element. Attributes are represented by an attribute name followed by an equal sign and the attribute value in quotation marks:
<TIMEFRAME>
In this example, the TIMEFRAME element contains another element, the BEGIN element. The BEGIN element has one attribute "restrict", with the value "1". The value for the element BEGIN is "1999-07-23". These two elements then make up a TIMEFRAME BEGIN date.
Each element has a unique name, referred to as the tag name. XML is case-sensitive in its processing of tag names. The IMS Enterprise/LMS interoperability XML binding specification adheres to the following tag name rules:
This specification defines external DTDs with defined file names, specifically IMS-EP01.dtd . Some XML editors may make use of a DTD to help guide the developer in creating the proper elements at the proper locations in an XML file. Other developers will make use of DTDs to validate their XML documents to ensure their document is consistent with all of the element names and locations defined in the DTD. An XML document is valid if it has an associated document type declaration and if the document complies with the constraints expressed in it. Details of the construction of DTDs are outside the scope of this document, but links to the XML Version 1.0 specification are included in the References section of this document.
The information specifying the order and usage of allowable
contents for an element are its content model. The content model is
declared in a Document Type Definition or DTD (see below). The
declaration of the content model is of the general form:
<!ELEMENT TAGNAME (Content Model)>
The SHORT element can again serve as an example of how an element is declared with its content model:
<!ELEMENT SHORT (#PCDATA)>
This element will contain processable character data (#PCDATA). The
majority of Enterprise/LMS elements are defined to contain #PCDATA. The
XML specification provides more information about the details for creating and interpreting content models.
An example of how the attributes for the element PROPERTIES is declared in a DTD is found below:
<!ELEMENT PROPERTIES (DATASOURCE,TARGET*,TYPE?,DATETIME,EXTENSION?) >
<!ATTLIST PROPERTIES
The first line declares that there is an element named "PROPERTIES" which must have the DATASOURCE, TARGET , and DATETIME elements and is additionally allowed to have TYPE and/or EXTENSION elements as its contents. The second line begins with "!ATTLIST" to start an attribute list declaration for the PROPERTIES element. The word "lang" will serve as the attribute's name. The allowable value for this attribute must be of type CDATA.
At the end of the example above is the term #IMPLIED. It is at this location in the attribute declaration, where a default value for an attribute may be specified. It is also possible to use the keyword #REQUIRED which would force a lang value to be supplied and there would be no default value. In the example above, the #IMPLIED designation means that the DTD designer wants to allow users to omit the value for the attribute without forcing a particular default value.
Within the IMS XML binding, the use of attributes is reserved for information about the structure of, and source of terms in, the meta-data record. It is recommended that attributes not be used for information about the resource. This IMS XML binding specification uses only one element attribute (the "restrict" attribute) in a particular way and for a particular purpose.
restrict:
This attribute specifies how the date should be adhered to for this element. For example:
<TIMEFRAME>
Typical codes for this attribute may be "0" or "1". Attribute valid values would be defined by a parameter entity.
A list is a repetition of the contents of an element. In XML, this is accomplished by repeating the containing element: For example, the PERSON element contains an element TEL for the telephone number. Described in the DTD as:
<!ELEMENT PERSON (SOURCEDID,PASSWORD?,NAME,DEMOGRAPHICS?,EMAIL?,TEL*,ADR?,EXTENSION?)>
<PERSON>
Note** There are mandatory elements for PERSON not shown in this example.
In this example, the element "TEL" is repeated. Thus TEL is the containing element for the repeated contents of "7607504785" and "7607503257" The notation for repetitions of an element in a content model follows the XML specification. An asterisk (*) specifies that none or more repetitions of the element may be included in the XML instantiation.
An Enterprise/LMS record must use UTF-8 or UTF-16 encoding of the character sets as defined in ISO 10646. See the XML Version 1.0 for more details on the specification of well-formed XML.
Element names under the PERSON element have been structured similar to vCard XML elements. This should aid developers translating vCard specific data. The element names follow the IMS standard as uppercased names. Should a developer want an exact vCard encoding, it should be encoded as an extension.
Some characters used in XML must be escaped when used outside of their XML defined usage as found in section 2.4 of the XML 1.0 specification. These characters are ampersand (&), less than (<), greater than (>), apostrophe ('), and the double-quote character (").
These characters may be represented using either numeric character references or the strings "&","<",">","'", and """.
Below is a more complete quote from the W3C XML standards:
Quote from Extensible Markup Language (XML) 1.0
W3C Recommendation 10-February-1998
2.4 Character Data and Markup
All text that is not markup constitutes the character data of the document.
The ampersand character (&) and the left angle bracket (<) may appear in their literal form only when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section. They are also legal within the literal entity value of an internal entity declaration; see "4.3.2 Well-Formed Parsed Entities". If they are needed elsewhere, they must be escaped using either numeric character references or the strings "&" and "<" respectively. The right angle bracket (>) may be represented using the string ">", and must, for compatibility, be escaped using ">" or a character reference when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section.
In the content of elements, character data is any string of characters which does not contain the start-delimiter of any markup. In a CDATA section, character data is any string of characters not including the CDATA-section-close delimiter, "]]>".
To allow attribute values to contain both single and double quotes, the apostrophe or single-quote character (') may be represented as "'", and the double-quote character (") as """."
Questions arose several times throughout the IMS Enterprise specification process, as to whether web-based data transmission tools might inadvertently strip off or transform some of the white space characters embedded in the Enterprise data transmitted between systems using XML. To eliminate concern about this issue, refer to the following quote from the W3C XML standards, which indicate that all white space must be preserved where it is part of the data.
Quote from Extensible Markup Language (XML) 1.0
W3C Recommendation 10-February-1998
2.10 White Space Handling
An XML processor must always pass all characters in a document that are not markup through to the application. A validating XML processor must also inform the application which of these characters constitute white space appearing in element content.
A special attribute named xml:space may be attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other, must be declared if it is used. When declared, it must be given as an enumerated type whose only possible values are "default" and "preserve". For example:
<!ATTLIST poem xml:space (default|preserve) 'preserve'>
The value "default" signals that applications' default white-space processing modes are acceptable for this element; the value "preserve" indicates the intent that applications preserve all the white space. This declared intent is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of the xml:space attribute. "
There are instances where elements described in the Information Model are implemented as attributes in the DTD. The following is an example of an instance:
Information Model Items :
2.7 Tel
are implemented in XML as
<TEL teltype="PREF">7607504785</TEL>
<TEL teltype="FAX">7607503257</TEL>
Other Information Model elements created as attributes in the DTD are:
1.5
2.2, 2.9.1, 2.9.2 3.2,
3.3.2.1, 3.6.1.2, 3.6.2.2, 3.10.3
4.2.3.1, 4.2.3.4, 4.2.3.8.1.2, 4.2.3.8.2.2, 4.2.3.9.2.1
Some providers will find the current element set defined in the Enterprise/LMS interoperability specification too restrictive to accomplish their purposes. To ensure extensibility, the specification requires that there be no limit on potential extensions on major elements PROPERTIES, PERSON, GROUP, and MEMBERSHIP. An extension is the addition of information to an existing XML structure.
<!ELEMENT EXTENSION ANY>
An example of the inclusion of EXTENSION in the content model of element PROPERTIES is:
<!ELEMENT PROPERTIES (DATASOURCE,TARGET*,TYPE,DATETIME,EXTENSION?)>
The use of the EXTENSION element is illustrated as follows:
<PROPERTIES>
<DATASOURCE>California State Univ. San Marcos</DATASOURCE>
<TARGET>College of Business LMS</TARGET>
<TYPE>REFRESH</TYPE>
<DATETIME>1999-02-03T12:15:33</DATETIME>
<EXTENSION>
The contents, but not a content model, of an extension must be declared in an internal or external DTD. Many extensions can be created through the use of existing elements. Care must be used with internal DTDs, as they override external DTD declarations. The content of an extension must obey the attribute and content models of the elements employed. New elements that duplicate the definitions of existing elements should not be introduced.
Prefacing the EXTENSION element with an appropriate namespace may reference descriptions of extensions. For example, a group such as the Advanced Distributed Learning (ADL) initiative may wish to add the "adl" prefix to an extension element to uniquely identify ADL extensions. An example of this is shown below:
<GROUP>
.. mandatory elements of GROUP elements here
<DESCRIPTION lang="en">
<SHORT>Military Training</SHORT>
</DESCRIPTION>
<EXTENSION adl:classification="Not classified" adl:title="Roman military
tactics">This example discusses how the Romans defined many aspects of modern
warfare.</EXTENSION>
</GROUP>
This serves to note the entire extension structure. Extensions should always be added at the lowest point (farthest from the root element) in the hierarchy possible, to the degree that the structure defines the meaning of the extension.
<!-- *************************************************************** -->
<!-- Title : IMS-EP01.dtd -->
<!-- Description : IMS Enterprise/LMS Interoperability DTD -->
<!-- -->
<!-- -->
<!-- Revision History -->
<!-- Date By Comments -->
<!-- *********** *********** *************************************** -->
<!-- 28 Oct,1999 Wayne Veres Initial Release of the XML Binding -->
<!-- as approved at the IMS Tech Board -->
<!-- Oct 15, 1999. Comments and structure -->
<!-- have been aligned to agree with the -->
<!-- structure of the Enterprise Information -->
<!-- model. -->
<!-- -->
<!-- -->
<!-- Document Structure -->
<!-- The elements of this document have been organized to follow -->
<!-- a similiar structure found in the information model -->
<!-- -->
<!-- Comments for the element will proceed the element in the -->
<!-- following format -->
<!-- Explanation : -->
<!-- Text for explanation -->
<!-- Type : -->
<!-- Text for type -->
<!-- Notes : -->
<!-- Text for note -->
<!-- When a domain of values is specified for an element it will -->
<!-- generally be restricted by an attribute for the element as -->
<!-- defined by an entity. Refer to the entity section for the values-->
<!-- and comments for the domain values. -->
<!-- -->
<!-- -->
<!-- Please use the following as a index to follow this DTD -->
<!-- -->
<!-- Document Root (i.e. ENTERPRISE) -->
<!-- Entities -->
<!-- Elements Common to all major roots -->
<!-- -->
<!-- Main objects and their elements will follow -->
<!-- -->
<!-- PROPERTIES -->
<!-- properties elements -->
<!-- PERSON root -->
<!-- person elements -->
<!-- GROUP root -->
<!-- group elements -->
<!-- MEMBERSHIP root -->
<!-- membership elements -->
<!-- -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- #### This is the Root element. #### -->
<!-- -->
<!ELEMENT ENTERPRISE (PROPERTIES,PERSON*,GROUP*,MEMBERSHIP*) >
<!-- -->
<!-- ############################ -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- ENTITIES -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- ............................................................... -->
<!-- An enumerated vocabulary for I_Value: -->
<!-- 0 = List -->
<!-- 1 = Range -->
<!-- ............................................................... -->
<!ENTITY % I_Value '
valuetype (0|1) "0"'>
<!-- ............................................................... -->
<!-- An enumerated vocabulary for I_Relation -->
<!-- Read as This is my child, This is my parent -->
<!-- It is describing the thing it is pointing too -->
<!-- 1 = Parent -->
<!-- 2 = Child -->
<!-- 3 = also known as -->
<!-- ............................................................... -->
<!ENTITY % I_Relation '
relation (1|2|3) "1"'>
<!-- ............................................................... -->
<!-- An enumerated vocabulary for I_Role -->
<!-- 01 = Learner -->
<!-- 02 = Instructor -->
<!-- 03 = Content Developer -->
<!-- 04 = Member -->
<!-- 05 = Manager -->
<!-- 06 = Mentor -->
<!-- 07 = Adminstrator -->
<!-- ............................................................... -->
<!ENTITY % I_Role '
roletype (01|02|03|04|05|06|07) "01"'>
<!-- ............................................................... -->
<!-- An enumerated vocabulary I_Recstatus : -->
<!-- 1 = Add -->
<!-- 2 = Update -->
<!-- 3 = Delete -->
<!-- ............................................................... -->
<!ENTITY % I_Recstatus '
recstatus (1|2|3) "1"'>
<!-- ............................................................... -->
<!-- An enumerated vocabulary: -->
<!-- 1 = Preferred Voice -->
<!-- 2 = FAX -->
<!-- ............................................................... -->
<!ENTITY % I_Tel '
teltype (1|2) "1"'>
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- I_Img value is an IANA registered image type -->
<!-- ............................................................... -->
<!ENTITY % I_Img "
imgtype CDATA #IMPLIED ">
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- ELEMENTS used by more then one object -->
<!-- Refer to the information model for specific information on -->
<!-- common elements -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- -->
<!-- Type : -->
<!-- String 32 -->
<!-- Notes : -->
<!-- -->
<!-- ............................................................... -->
<!ELEMENT TYPE (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- An identifier for the source system. -->
<!-- Type : -->
<!-- Source String 32 -->
<!-- ID String 256 -->
<!-- Notes : -->
<!-- SOURCE Identifier of the organization or system that created -->
<!-- the group object. -->
<!-- ID Permanently unique identifier for as defined by the system-->
<!-- where the object was created. -->
<!-- ............................................................... -->
<!ELEMENT SOURCEDID (SOURCE,ID) >
<!ELEMENT SOURCE (#PCDATA) >
<!ELEMENT ID (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- Person's user ID as defined for the object -->
<!-- ............................................................... -->
<!ELEMENT USERID (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- Email address used to contact a member for information related-->
<!-- to a specific object -->
<!-- ............................................................... -->
<!ELEMENT EMAIL (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- -->
<!-- Type : -->
<!-- Any valid element, PCDATA -->
<!-- Notes : -->
<!-- Acts as the high level element for any extensions to the data -->
<!-- object. -->
<!-- ............................................................... -->
<!ELEMENT EXTENSION ANY>
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- Main Objects -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- #### This is the PROPERTY object #### -->
<!-- -->
<!-- ############################ -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- When a source system generates one or more data objects, it must-->
<!-- include some basic packaging and control data that the target -->
<!-- system or systems use to determine the source, timing and type -->
<!-- of event that has caused the generation of a data package. -->
<!-- This information is used to manage the interchange of data -->
<!-- between systems. -->
<!-- The lang attribute would imply this is the language for the -->
<!-- entire contents of this file -->
<!ELEMENT PROPERTIES (DATASOURCE,TARGET*,TYPE?,DATETIME,EXTENSION?) >
<!ATTLIST PROPERTIES
lang CDATA #IMPLIED >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- An identifier for the source system. -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- Allows the target system(s) to identify the system that -->
<!-- generated the data objects. -->
<!-- Value must be unique for each source. -->
<!-- ............................................................... -->
<!ELEMENT DATASOURCE (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Identifier for a target system. -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- If the data objects are intended for one or more specific -->
<!-- target systems, this element identifies those systems. -->
<!-- Must use the same system naming scheme as is used for data -->
<!-- source. -->
<!-- ............................................................... -->
<!ELEMENT TARGET (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Describes the type of event that caused the source system to -->
<!-- generate the data objects. -->
<!-- Type : -->
<!-- String 32 -->
<!-- Notes : -->
<!-- A standard set of codes must be agreed upon for any -->
<!-- specific implementation. -->
<!-- ............................................................... -->
<!-- TYPE is defined in the common elements section -->
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Date and time the data objects were generated by the data -->
<!-- source. -->
<!-- Type : -->
<!-- ISO8601 -->
<!-- ............................................................... -->
<!ELEMENT DATETIME (#PCDATA) >
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- #### This is the PERSON object #### -->
<!-- -->
<!-- ############################ -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- When a person data object is passed, the target system will -->
<!-- update its files with the data in the object. If a person is -->
<!-- new, they will be added to the system. If a person's data has -->
<!-- changed, the new data should be used to update the target -->
<!-- system. If a person is flagged for deletion, it is up to the -->
<!-- target system to determine what action to take with that -->
<!-- deletion information. -->
<!-- -->
<!-- Note that the target system needs to be capable of storing the -->
<!-- source system's 'Sourced ID', which is used to uniquely -->
<!-- identify a person within the implementation environment. This -->
<!-- is required to support future updates of person information -->
<!-- from the source system. -->
<!-- ............................................................... -->
<!ELEMENT PERSON (SOURCEDID,USERID?,NAME,DEMOGRAPHICS?,EMAIL?,TEL*,ADR?,PHOTO?,DATASOURCE?, EXTENSION?)>
<!ATTLIST PERSON
%I_Recstatus; >
<!-- ............................................................... -->
<!-- SOURCEDID,USERID? are defined in the common elements section -->
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- The name of the person. -->
<!-- Notes : -->
<!-- Note that the name parts specified below are to support -->
<!-- interoperability, not to maintain a full record of a -->
<!-- person's names. -->
<!-- ............................................................... -->
<!ELEMENT NAME (FN,SORT?,NICKNAME?,N?) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Formatted name -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- -->
<!-- ............................................................... -->
<!ELEMENT FN (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Name 'parsed' and re-ordered so it will sort appropriately on-->
<!-- an alphabetized report or online panel. This name is never -->
<!-- displayed, it is only used to sort. -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- 'Parsing' schemes will be vendor specific. The examples at -->
<!-- right use a scheme that concatenates the first five letters -->
<!-- of family name followed by the first five of Given name. -->
<!-- ............................................................... -->
<!ELEMENT SORT (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Full name formatted in the way that the person prefers to be -->
<!-- addressed. -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- -->
<!-- ............................................................... -->
<!ELEMENT NICKNAME (#PCDATA)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Name with all parts distinguished -->
<!-- ............................................................... -->
<!ELEMENT N (FAMILY?,GIVEN?,OTHER*,PREFIX?,SUFFIX?) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Note that this is the Family name, not the Last name. The -->
<!-- order of name parts varies by culture. -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- -->
<!-- ............................................................... -->
<!ELEMENT FAMILY (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Given name, not necessarily first name. The order of name -->
<!-- parts varies by culture. -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- -->
<!-- ............................................................... -->
<!ELEMENT GIVEN (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Other name parts -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- -->
<!-- ............................................................... -->
<!ELEMENT OTHER (#PCDATA)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- -->
<!-- Type : -->
<!-- String 32 -->
<!-- Notes : -->
<!-- Mr, Mrs, Ms, Mssr, Dr, etc. -->
<!-- ............................................................... -->
<!ELEMENT PREFIX (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- -->
<!-- Type : -->
<!-- String 32 -->
<!-- Notes : -->
<!-- Jr, III, Sr, etc -->
<!-- ............................................................... -->
<!ELEMENT SUFFIX (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Demographic information about the person -->
<!-- Notes : -->
<!-- Minimal demographic information is specified. What is here -->
<!-- is useful for the confirmation of identity. Other data -->
<!-- elements such as citizenship, ethnicity and place of birth -->
<!-- have been considered for the standard specification, but no -->
<!-- specific interoperability need has been found for these -->
<!-- elements as yet. -->
<!-- ............................................................... -->
<!ELEMENT DEMOGRAPHICS (GENDER?,BDAY?) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Gender of the person. -->
<!-- Type : -->
<!-- String 1 -->
<!-- Notes : -->
<!-- 0 = unknown, 1 = female, 2 = male -->
<!-- ............................................................... -->
<!ELEMENT GENDER (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Date the person was born. -->
<!-- Type : -->
<!-- Date in ISO8601 standard format -->
<!-- Notes : -->
<!-- -->
<!-- ............................................................... -->
<!ELEMENT BDAY (#PCDATA) >
<!-- ............................................................... -->
<!-- EMAIL is defined in the common elements section -->
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Telephone number used to contact a person. -->
<!-- Type : -->
<!-- String 32 -->
<!-- Notes : -->
<!-- Attribute 1 = Voice, 2 = Fax -->
<!-- ............................................................... -->
<!ELEMENT TEL (#PCDATA)>
<!ATTLIST TEL
%I_Tel;>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Address used to deliver physical objects to a person. -->
<!-- Notes : -->
<!-- No repeatability is supported in the spec because no -->
<!-- specific interoperability need has been identified for more -->
<!-- than one Address. -->
<!-- ............................................................... -->
<!ELEMENT ADR (POBOX?, EXTADD?, STREET*, LOCALITY?, REGION?,PCODE?, COUNTRY?)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Post Office Box -->
<!-- Type : -->
<!-- String 32 -->
<!-- Notes : -->
<!-- -->
<!-- ............................................................... -->
<!ELEMENT POBOX (#PCDATA)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Extra address data -->
<!-- Type : -->
<!-- String 128 -->
<!-- Notes : -->
<!-- Any 'non street' components of the address, Suite number, -->
<!-- company name, care of, etc, -->
<!-- ............................................................... -->
<!ELEMENT EXTADD (#PCDATA)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Street address -->
<!-- Type : -->
<!-- String 128 -->
<!-- Notes : -->
<!-- Ordered list. Should be used in the order presented -->
<!-- ............................................................... -->
<!ELEMENT STREET (#PCDATA)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Locality -->
<!-- Type : -->
<!-- String 64 -->
<!-- Notes : -->
<!-- City is one example of Locality -->
<!-- ............................................................... -->
<!ELEMENT LOCALITY (#PCDATA)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Region -->
<!-- Type : -->
<!-- String 64 -->
<!-- Notes : -->
<!-- State and Province are examples of Region -->
<!-- ............................................................... -->
<!ELEMENT REGION (#PCDATA)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Postal Code -->
<!-- Type : -->
<!-- String 32 -->
<!-- Notes : -->
<!-- Format of postal code varies by country. -->
<!-- ............................................................... -->
<!ELEMENT PCODE (#PCDATA)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Country -->
<!-- Type : -->
<!-- String 64 -->
<!-- Notes : -->
<!-- Codes specified in ISO 3166 -->
<!-- ............................................................... -->
<!ELEMENT COUNTRY (#PCDATA)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Reference to an external location containing a photo of the -->
<!-- person. -->
<!-- Notes : -->
<!-- I_Img - The type of image referred to -->
<!-- ............................................................... -->
<!ELEMENT PHOTO (EXTREF)>
<!ATTLIST PHOTO
%I_Img;>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- The reference to an external location. -->
<!-- Type : -->
<!-- String 1024 -->
<!-- Notes : -->
<!-- Could be a URL. Web standards for location references are -->
<!-- not finalized. When they are, this spec will incorporate -->
<!-- them. -->
<!-- ............................................................... -->
<!ELEMENT EXTREF (#PCDATA)>
<!ATTLIST EXTREF
value (URI|TEXT) "URI">
<!-- ............................................................... -->
<!-- EXTENSION is defined in the common elements section -->
<!-- ............................................................... -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- #### This is the GROUP object #### -->
<!-- -->
<!-- ############################ -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- When a group data object is passed, the target system will -->
<!-- update its files with the data in the object. If a group is -->
<!-- new, it will be added to the system. If a group's data has -->
<!-- changed, the new data should be used to update the target -->
<!-- system. . If a group is flagged for deletion, it is up to the -->
<!-- target system to determine what action to take with that -->
<!-- deletion information. -->
<!-- Note that the target system needs to be capable of storing the -->
<!-- source system's 'Sourced ID', which is used to uniquely -->
<!-- identify a group within the implementation environment. This -->
<!-- is required to support future updates of group information -->
<!-- from the source system. -->
<!-- It is possible to have a viable interface without automatically -->
<!-- exchanging Group data, but this then means that one or the other-->
<!-- of the systems involved in an interface must first store the -->
<!-- other system's Group Identifier in order to support the passing -->
<!-- of Group membership data. -->
<!-- ............................................................... -->
<!ELEMENT GROUP (SOURCEDID,GROUPTYPE*,DESCRIPTION,ORG?,TIMEFRAME?,
ENROLLCONTROL?,EMAIL?,URL?,RELATIONSHIP*,DATASOURCE?,EXTENSION?) >
<!ATTLIST GROUP
%I_Recstatus; >
<!-- ............................................................... -->
<!-- SOURCEDID is defined in the common elements section -->
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Defines what type of group this is. -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- This element provides a structure that allows a Group to be -->
<!-- categorized into one or more coding schemes, with any number-->
<!-- of levels supported within each scheme. -->
<!-- ............................................................... -->
<!ELEMENT GROUPTYPE (SCHEME?,TYPEVALUE+) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Group Type coding scheme -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- Identifies which Group categorization scheme is being used. -->
<!-- This could be a proprietary vendor taxonomy, a national -->
<!-- subject area taxonomy, etc. -->
<!-- ............................................................... -->
<!ELEMENT SCHEME (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Value of the for the group type as allowed by the scheme -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- Repeats to allow more than one level of code to be stored. -->
<!-- Level attribute should be used to indicate an order of -->
<!-- values -->
<!-- ............................................................... -->
<!ELEMENT TYPEVALUE (#PCDATA) >
<!ATTLIST TYPEVALUE
level CDATA #REQUIRED >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Description / Name of the Group. -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- -->
<!-- ............................................................... -->
<!ELEMENT DESCRIPTION (SHORT,LONG?,FULL?)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Intended to be displayed on screen on less than one line. -->
<!-- Type : -->
<!-- String 60 -->
<!-- Notes : -->
<!-- Usually something brief such as 'ENGLISH 101A SECTION 4'. -->
<!-- ............................................................... -->
<!ELEMENT SHORT (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Longer descriptive name for the group. -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- English 101A - Great Authors of the 19th and 20th Century -->
<!-- ............................................................... -->
<!ELEMENT LONG (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- A longer description of the group. -->
<!-- Type : -->
<!-- String 2048 -->
<!-- Notes : -->
<!-- For example, the 'catalog' description of a course. -->
<!-- ............................................................... -->
<!ELEMENT FULL (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- The organization administering or 'sponsoring' the Group. -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- For example, Cal State San Marcos would be the administrator-->
<!-- of a course section offered on their campus. -->
<!-- ............................................................... -->
<!ELEMENT ORG (ORGNAME, ORGUNIT*,TYPE?,ID?)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- The name of the organization. -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- 'Cal State San Marcos' -->
<!-- ............................................................... -->
<!ELEMENT ORGNAME (#PCDATA)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Name of sponsoring or administering unit within the -->
<!-- organization -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- One or more departments or units can sponsor the group. -->
<!-- 0158 - Math Department -->
<!-- ............................................................... -->
<!ELEMENT ORGUNIT (#PCDATA)>
<!-- ............................................................... -->
<!-- TYPE is defined in the common elements section -->
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- ID of the organization -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- If there is a code for the organization, it can be specified-->
<!-- separately in this field. -->
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- ID is defined in the common elements section -->
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Time frame when the group is active. -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- -->
<!-- ............................................................... -->
<!ELEMENT TIMEFRAME (BEGIN?,END?,ADMINPERIOD?) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Date of availability. -->
<!-- Type : -->
<!-- ISO8601 -->
<!-- Notes : -->
<!-- restrict attribute Do not allow learner participation until -->
<!-- the begin date -->
<!-- ............................................................... -->
<!ELEMENT BEGIN (#PCDATA) >
<!ATTLIST BEGIN
restrict CDATA #REQUIRED >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Defines when group participation is intended to end. -->
<!-- Type : -->
<!-- ISO8601 -->
<!-- Notes : -->
<!-- restrict attribute Do not allow learner participation until -->
<!-- the begin date -->
<!-- ............................................................... -->
<!ELEMENT END (#PCDATA) >
<!ATTLIST END
restrict CDATA #REQUIRED >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Short descriptive name in human readable form for the -->
<!-- administrative or academic period within which the group -->
<!-- exists -->
<!-- Type : -->
<!-- String 32 -->
<!-- Notes : -->
<!-- -->
<!-- ............................................................... -->
<!ELEMENT ADMINPERIOD (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- -->
<!-- ............................................................... -->
<!ELEMENT ENROLLCONTROL (ENROLLACCEPT?,ENROLLALLOWED?) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Indicates if the Group is accepting enrollments -->
<!-- Type : -->
<!-- 0 = no , 1 = yes -->
<!-- Notes : -->
<!-- There can be different reasons for a group being closed. -->
<!-- It may be full, it may be cancelled. -->
<!-- ............................................................... -->
<!ELEMENT ENROLLACCEPT (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Can the target system enroll people? -->
<!-- Type : -->
<!-- 0 = no , 1 = yes -->
<!-- Notes : -->
<!-- If No, then only the source system can enroll people. -->
<!-- ............................................................... -->
<!ELEMENT ENROLLALLOWED (#PCDATA) >
<!-- ............................................................... -->
<!-- EMAIL is defined in the common elements section -->
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- URL for a group -->
<!-- Type : -->
<!-- String 256 -->
<!-- Notes : -->
<!-- For a course, this would be the course home page. -->
<!-- ............................................................... -->
<!ELEMENT URL (#PCDATA) >
<!ATTLIST URL
value (URI|TEXT) "URI">
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- If the group is related to another group, then this Element -->
<!-- can be used to describe that relationship -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- The relationship described is the relationship of the group -->
<!-- in the relationship to the Group defined in the Group -->
<!-- object. For example, if the Label element says 'Subgroup' -->
<!-- and the Relation element is '2' (child), then the group in -->
<!-- this element is a subgroup and a child of the group defined -->
<!-- in the group object. -->
<!-- -->
<!-- Note that this relationship segment should not be used to -->
<!-- store 'membership' in other groups. The Group membership -->
<!-- construct is used for that type of role based membership. -->
<!-- -->
<!-- Relation attribute 1=parent, 2=child, 3 =also known as -->
<!-- ............................................................... -->
<!ELEMENT RELATIONSHIP (SOURCEDID,LABEL) >
<!ATTLIST RELATIONSHIP
I_Relation CDATA #IMPLIED >
<!-- ............................................................... -->
<!-- SOURCEDID is defined in the common elements section -->
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Describes the nature of the relationship between this group -->
<!-- and the related group. -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- "Course Subgroup", "Cross Listed Course Section" -->
<!-- ............................................................... -->
<!ELEMENT LABEL (#PCDATA) >
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- #### This is the MEMBERSHIP object #### -->
<!-- -->
<!-- ############################ -->
<!-- *************************************************************** -->
<!-- *************************************************************** -->
<!-- This object is primarily intended to pass group membership -->
<!-- information from systems that manage various types of group -->
<!-- enrollment processes to the systems that provide learning -->
<!-- management services to those group members. Note that the -->
<!-- enrollment processes referred to here include a wide range of -->
<!-- specific functionality, including but not limited to examples -->
<!-- such as: -->
<!-- enrollment in a course, -->
<!-- employment in a particular company division, or -->
<!-- membership in a club. -->
<!-- In addition, it allows final result data to be exchanged -->
<!-- (typically final grade or a completion indicator) so it can also-->
<!-- be used to pass the final result data back from the learning -->
<!-- system to the enterprise systems. -->
<!-- When a membership data object is passed, the target system will -->
<!-- update its files with the data in the object. If a membership -->
<!-- is new, it will be added to the system. If a membership -->
<!-- record's data has changed, the new data should be used to update-->
<!-- the target system. . If a membership is flagged for deletion, -->
<!-- it is up to the target system to determine what action to take -->
<!-- with that deletion information. -->
<!-- ............................................................... -->
<!ELEMENT MEMBERSHIP (SOURCEDID,MEMBER*) >
<!-- ............................................................... -->
<!-- SOURCEDID is defined in the common elements section -->
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Group Member -->
<!-- ............................................................... -->
<!ELEMENT MEMBER (SOURCEDID,IDTYPE,ROLE+) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Indicates if the member is a person, or another group. -->
<!-- Type : -->
<!-- 1 = Person, 2 = Group -->
<!-- Notes : -->
<!-- -->
<!-- ............................................................... -->
<!ELEMENT IDTYPE (#PCDATA)>
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- A member can have multiple roles in a group (for example -->
<!-- Learner and Instructor). These would be reflected in -->
<!-- separate occurrences of the Role element. -->
<!-- attribute I_role 01=Learner -->
<!-- 02=Instructor -->
<!-- 03=Content Developer -->
<!-- 04=Member -->
<!-- 05=Manager -->
<!-- 06=Mentor -->
<!-- 07=Administrator -->
<!-- ............................................................... -->
<!ELEMENT ROLE (SUBROLE?,STATUS,USERID?,COMMENTS?,DATE?, TIMEFRAME?,FINALRESULT?,EMAIL?,DATASOURCE?, EXTENSION?) >
<!ATTLIST ROLE
%I_Recstatus;
%I_Role; >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Further qualifies a member's role in the group -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- For an Instructor RoleType, -->
<!-- examples are: -->
<!-- Primary Instructor, Teaching Assistant,Tutor -->
<!-- ............................................................... -->
<!ELEMENT SUBROLE (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Indicates if a member is active or inactive in the group. -->
<!-- Type : -->
<!-- 0 = Inactive,1 = Active -->
<!-- Notes : -->
<!-- This allows the source system to specifically tell the -->
<!-- target system that a member is now active or inactive. -->
<!-- Another view is that the absence of a membership record when-->
<!-- membership data is passed implies inactivity, and the -->
<!-- existence of a record implies active membership. This will -->
<!-- logically work for a 'snapshot' interface where all members -->
<!-- are passed every time objects are passed from one system to -->
<!-- another, but it will not support an interface where -->
<!-- individual membership records are passed. -->
<!-- ............................................................... -->
<!ELEMENT STATUS (#PCDATA) >
<!-- ............................................................... -->
<!-- USERID is defined in the common elements section -->
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Description of the current status. -->
<!-- Type : -->
<!-- String 2048 -->
<!-- Notes : -->
<!-- May be used to describe why a member's status changed, or -->
<!-- simply to record more detail about a member's status in the -->
<!-- group. -->
<!-- ............................................................... -->
<!ELEMENT COMMENTS (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Date the current membership was established -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- ISO 8601 -->
<!-- ............................................................... -->
<!ELEMENT DATE (#PCDATA) >
<!-- ............................................................... -->
<!-- TIMEFRAME is defined in the group object section -->
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Final result codes and value. -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- The specification allows for the passing of a group -->
<!-- member's final result mode and all valid result values -->
<!-- from the source system to the target system. It is -->
<!-- provided at the Group member level because it can vary for -->
<!-- different members of a group ( one learner could be -->
<!-- on a graded basis, another pass/fail, and another auditing,-->
<!-- with no valid result codes. -->
<!-- The specification also allows for the passing of a group -->
<!-- member's final result, both a result code and result -->
<!-- description. -->
<!-- ............................................................... -->
<!ELEMENT FINALRESULT (MODE?,VALUES?,RESULT?,COMMENTS?) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Short descriptive name for final result grading mode. -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- 'Letter Grade','Pass/Fail','Percentage','Attendance' -->
<!-- ............................................................... -->
<!ELEMENT MODE (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Valid result values. -->
<!-- Type : -->
<!-- String 2048 -->
<!-- Notes : -->
<!-- Used to tell the target system what final result values -->
<!-- are valid to assign to a learner. -->
<!-- ............................................................... -->
<!ELEMENT VALUES (LIST*, MIN?, MAX?) >
<!ATTLIST VALUES
%I_Value; >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- A specific result value -->
<!-- Type : -->
<!-- String 32 -->
<!-- Notes : -->
<!-- The list contains the valid grades if Value Type = 0 -->
<!-- ............................................................... -->
<!ELEMENT LIST (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Maximum value -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- Used if I_Value = 1 -->
<!-- ............................................................... -->
<!ELEMENT MAX (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Minimum value -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- Used if I_Value = 1 -->
<!-- ............................................................... -->
<!ELEMENT MIN (#PCDATA) >
<!-- ............................................................... -->
<!-- Explanation : -->
<!-- Value of final result assigned to the member for -->
<!-- participation in the group. -->
<!-- Type : -->
<!-- -->
<!-- Notes : -->
<!-- Ideally, this would be one of the values from the Result -->
<!-- values list -->
<!-- ............................................................... -->
<!ELEMENT RESULT (#PCDATA) >
<!-- ............................................................... -->
<!-- COMMENTS is defined above.This is a comment for the final result-->
<!-- ............................................................... -->
<!-- ............................................................... -->
<!-- EMAIL is defined in the common elements section -->
<!-- ............................................................... -->
This is an example of 2 persons-- 1 group and a group membership for the group consisting of the 2 persons. ( 1 a student and the other the professor).
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ENTERPRISE SYSTEM "IMS-EP01.dtd" >
<ENTERPRISE>
<PROPERTIES>
<DATASOURCE>California State University San Marcos</DATASOURCE>
<TARGET>Computing and Telecommunications LMS</TARGET>
<TYPE>REFRESH</TYPE>
<DATETIME>1999-02-03</DATETIME>
</PROPERTIES>
<PERSON transaction="1">
<SOURCEDID>
<SOURCE>California State University San Marcos</SOURCE>
<ID>88-99-0102</ID>
</SOURCEDID>
<NAME>
<FN>Stanley Wang</FN>
</NAME>
</PERSON>
<PERSON transaction="1">
<SOURCEDID>
<SOURCE>California State University San Marcos</SOURCE>
<ID>111-22-3344</ID>
</SOURCEDID>
<NAME>
<FN>Wayne Veres</FN>
<SORT>Veres, Wayne</SORT>
<NICKNAME>Wayne</NICKNAME>
<N>
<FAMILY>Veres</FAMILY>
<GIVEN>Wayne</GIVEN>
<PREFIX>Mr.</PREFIX>
</N>
</NAME>
<DEMOGRAPHICS>
<GENDER>2</GENDER>
<BDAY>1956-02-03</BDAY>
</DEMOGRAPHICS>
<EMAIL>veres@mailhost1.csusm.edu</EMAIL>
<TEL teltype="1">7607504785</TEL>
<TEL teltype="2">7607503257</TEL>
<ADR>
<STREET>Twin Oaks Valley Rd</STREET>
<LOCALITY>San Marcos</LOCALITY>
<REGION>CA</REGION>
<PCODE>92096-0001</PCODE>
</ADR>
</PERSON>
<GROUP transaction="1">
<SOURCEDID>
<SOURCE>College of Arts and Sciences</SOURCE>
<ID>CS 697C Section 1 Fall 1999</ID>
</SOURCEDID>
<DESCRIPTION>
<SHORT>Security In Computing</SHORT>
<LONG>Graduate Level Special Topics course covering security in computing today.</LONG>
<FULL>This course will examine threats and security issues in today's common computing environments. Prerequisites: Advanced Networks (CS 622) and Cryptography (CS 633).</FULL>
</DESCRIPTION>
<ORG>
<ORGNAM>College of Arts and Sciences</ORGNAM>
<ORGUNIT>Computer Science</ORGUNIT>
<TYPE>Academic</TYPE>
</ORG>
<TIMEFRAME>
<BEGIN restrict="0">1999-08-26</BEGIN>
<END restrict="0">1999-12-20</END>
<ADMINPERIOD>Fall 1999</ADMINPERIOD>
</TIMEFRAME>
<ENROLLCONTROL>
<ENROLLACCEPT>1</ENROLLACCEPT>
</ENROLLCONTROL>
</GROUP>
<MEMBERSHIP>
<SOURCEDID>
<SOURCE>College of Arts and Sciences</SOURCE>
<ID>CS 697C Section 1 Fall 1999</ID>
</SOURCEDID>
<MEMBER>
<SOURCEDID>
<SOURCE>California State University San Marcos</SOURCE>
<ID>111-22-3344</ID>
</SOURCEDID>
<IDTYPE idtype="1"/>
<ROLE transaction="1" roletype="01">
<STATUS>1</STATUS>
<COMMENTS>This student has no special needs.</COMMENTS>
<FINALRESULT>
<MODE>Letter Grade requested</MODE>
<VALUES listrange="0">
<LIST>A</LIST>
<LIST>C</LIST>
<LIST>F</LIST>
</VALUES>
</FINALRESULT>
</ROLE>
</MEMBER>
<MEMBER>
<SOURCEDID>
<SOURCE>California State University San Marcos</SOURCE>
<ID>88-99-0102</ID>
</SOURCEDID>
<IDTYPE idtype="1"/>
<ROLE transaction="1" roletype="02">
<SUBROLE>PRIMARY</SUBROLE>
<STATUS>1</STATUS>
</ROLE>
</MEMBER>
</MEMBERSHIP>
</ENTERPRISE>
ISO/IEC 10646
ISO (International Organization for Standardization). ISO/IEC
10646-1993 (E). Information technology -- Universal Multiple-Octet
Coded Character Set (UCS) -- Part 1: Architecture and Basic
Multilingual Plane. [Geneva]: International Organization for
Standardization, 1993 (plus amendments AM 1 through AM 7).
Unicode
The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.
XML
XML Version 1.0 specification of the W3C: http://www.w3.org/TR/1998/REC-xml-19980210
XML Namespaces
XML Namespace Recommendation of W3C: http://www.w3.org/TR/1999/REC-xml-names-19990114
Changes to the v1.0 of the IMS Enterprise XML Binding are as follows:
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Inconsistency between the Information Model and the DTDtransaction should be called recstatus. |
| References in Document | Enterprise/LMS Interoperability DTD p. 10 |
| Solution Proposed by the Submitter | The following lines should be changed:1)
<!ENTITY % I_Recstatus ' Should be replaced with < !ENTITY % I_Recstatus ' |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Inconsistency between the Information Model and the DTDAttribute should not be required. |
| References in Document | Enterprise/LMS Interoperability DTD p. 10 |
| Solution Proposed by the Submitter | 2)The following lines should be changed:<!ENTITY % I_Img " Should be replaced with <!ENTITY % I_Img " |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Inconsistency between the Information Model and the DTD No lang attribute for element DESCRIPTION |
| References in Document | Enterprise/LMS Interoperability DTD p. 20 |
| Solution Proposed by the Submitter | 3)The following lines should be changed:<!ELEMENT DESCRIPTION (SHORT,LONG?,FULL?) Should be replaced with
<!ELEMENT DESCRIPTION (SHORT,LONG?,FULL?) > |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Inconsistency between the Information Model and the DTD ORGNAM should be spelled ORGNAME |
| References in Document | Enterprise/LMS Interoperability DTD p. 20 |
| Solution Proposed by the Submitter | 4)The following lines should be changed:<!ELEMENT ORG (ORGNAM?, ORGUNIT*,TYPE?,ID?)> Should be replaced with
<!ELEMENT ORG (ORGNAME, ORGUNIT*,TYPE?,ID?)> |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Inconsistency between the Information Model and the DTD myrelation should be called relation |
| References in Document | Enterprise/LMS Interoperability DTD p. 9 |
| Solution Proposed by the Submitter | 5)The following lines should be changed:<!ENTITY % I_Relation ' Should be replaced with
<!ENTITY % I_Relation ' |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Inconsistency between the Information Model and the DTD No longer used |
| References in Document | Enterprise/LMS Interoperability DTD p. 10 |
| Solution Proposed by the Submitter | 6)Delete the following lines
<!-- ............................................................... --> |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Inconsistency between the Information Model and the DTD No longer used |
| References in Document | Enterprise/LMS Interoperability DTD p. 24 |
| Solution Proposed by the Submitter | 7)Delete the following lines
<!ATTLIST IDTYPE |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Inconsistency between the Information Model and the DTD Add element DATE? |
| References in Document | Enterprise/LMS Interoperability DTD p. 25 |
| Solution Proposed by the Submitter | 8)The following lines should be changed:<!ELEMENT ROLE Should be replaced with <!ELEMENT ROLE |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Inconsistency between the Information Model and the DTD Add element DATE |
| References in Document | Enterprise/LMS Interoperability DTD p. 25 |
| Solution Proposed by the Submitter | 9)Add the following lines :<!-- ............................................................... --> |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Inconsistency between the Information Model and the DTD Rename listrange to valuetype |
| References in Document | Enterprise/LMS Interoperability DTD p. 9 |
| Solution Proposed by the Submitter | 10)The following lines should be changed:<!ENTITY % I_Value ' Should be replaced with <!ENTITY % I_Value ' |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Inconsistency between the Information Model and the DTD Make SCHEME optional |
| References in Document | Enterprise/LMS Interoperability DTD p. 19 |
| Solution Proposed by the Submitter | 11)The following lines should be changed:<!ELEMENT GROUPTYPE (SCHEME,TYPEVALUE+) > Should be replaced with <!ELEMENT GROUPTYPE (SCHEME?,TYPEVALUE+) > |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Inconsistency between the Information Model and the DTD Make element DESCRITPION mandatory and non repeating |
| References in Document | Enterprise/LMS Interoperability DTD p. 19 |
| Solution Proposed by the Submitter | 12)The following lines should be changed:<!ELEMENT GROUP (SOURCEDID,GROUPTYPE*,DESCRIPTION+,ORG?,TIMEFRAME?, Should be replaced with <!ELEMENT GROUP (SOURCEDID,GROUPTYPE*,DESCRIPTION,ORG?,TIMEFRAME?, |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Addition Add element DATASOURCE? |
| References in Document | Enterprise/LMS Interoperability DTD p. 13 |
| Solution Proposed by the Submitter | 13)The following lines should be changed:<!ELEMENT PERSON (SOURCEDID,USERID?,NAME,DEMOGRAPHICS?,EMAIL?,TEL*,ADR?, Should be replaced with <!ELEMENT PERSON (SOURCEDID,USERID?,NAME,DEMOGRAPHICS?,EMAIL?,TEL*,ADR?,PHOTO?, |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Addition Add element DATASOURCE? |
| References in Document | Enterprise/LMS Interoperability DTD p. 19 |
| Solution Proposed by the Submitter | 14)The following lines should be changed:<!ELEMENT GROUP (SOURCEDID,GROUPTYPE*,DESCRIPTION+,ORG?,TIMEFRAME?, Should be replaced with <!ELEMENT GROUP (SOURCEDID,GROUPTYPE*,DESCRIPTION+,ORG?,TIMEFRAME?, |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Addition Add element DATASOURCE? |
| References in Document | Enterprise/LMS Interoperability DTD p. 25 |
| Solution Proposed by the Submitter | 15)The following lines should be changed:<!ELEMENT ROLE (SUBROLE?,STATUS,USERID?,COMMENTS?,DATE?, Should be replaced with <!ELEMENT ROLE (SUBROLE?,STATUS,USERID?,COMMENTS?,DATE?,TIMEFRAME?,FINALRESULT?,EMAIL?, |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Clarification Describes how elements named in the Info Model may be implemented as attributes in XML |
| References in Document | Enterprise/LMS Interoperability DTD p. 4 |
| Solution Proposed by the Submitter | 16)Information Model/DTD Implementation Issues There are instances where elements described in the Information Model are implemented as attributes in the DTD. The following is an example of an instance: Information Model Items :
are implemented in XML as
Other Information Model elements created as attributes in the DTD are: |
| Type of Problem | Technical Error |
| Date | December 14, 1999 |
| Problem Description | Inconsistency between the Information Model and the DTD Attribute was spelled incorrectly |
| References in Document | Enterprise/LMS Interoperability DTD p. 21 |
| Solution Proposed by the Submitter | 17)The following lines should be changed: <TEL tel.type="PREF">7607504785</TEL> Should be replaced with <TEL teltype="PREF">7607504785</TEL> |
| Type of Problem | Technical Error |
|---|---|
| Date | December 14, 1999 |
| Problem Description | Inconsistency in element name. Rename ORGNAM to ORGNAME |
| References in Document | Enterprise/LMS Interoperability DTD p. 4 |
| Solution Proposed by the Submitter | 18)The following lines should be changed:>!ELEMENT ORGNAM (#PCDATA)< Should be replaced with >!ELEMENT ORGNAME (#PCDATA)< |
| Title | IMS Enterprise / Interoperability XML Binding Specification |
| Authors | Geoff Collier, Wayne Veres |
| Version | 1.01 |
| Version Date | December 21, 1999 |
| Status | Final |
| Summary | The XML encoding is based on the W3C XML specification version 1.0. A mixture of attributed and tagged forms is used. Attributes provide some of the meta-data structure definitions, but do not contain information about the resource. |
| Revision Information | Last revised December 21, 1999 |
| Purpose | Defines how the Enterprise Systems Information Model is encoded in XML by IMS. |
| Document Location | http://www.imsproject.org/enterprise/enbind03.pdf |
IMS Global Learning Consortium, Inc.
(“IMS”) is publishing the information contained in this IMS
Enterprise XML Binding (“Specification”) for purposes of
scientific, experimental, and scholarly collaboration only.
IMS 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.
IMS would appreciate receiving your comments and suggestions.
Please contact IMS through our website at http://www.imsproject.org
Please refer to Document Name: IMS Enterprise XML Binding v1.01 Revision: December 1999