 |
1EdTech Enterprise XML Binding Specification
Version 1.01 - Final Specification |
Copyright © 1999 1EdTech Consortium, Inc. All Rights Reserved.
The 1EdTech Logo is a trademark of 1EdTech Consortium, Inc.
Document Name: 1EdTech 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.
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: /imsipr_policyFinal.pdf.
Copyright © 1999 1EdTech Consortium. All Rights Reserved.
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.
Introduction
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 XML binding will adhere to the XML Version 1.0 specification of the W3C.It must maintain the definitional structure of the specification.It must permit extensions for major elements (PROPERTIES, PERSON, GROUP, and GROUPMEMBERSHIP).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>
Element Contents
An element may contain other elements, Parsed Character Data (PCDATA), Character Data (CDATA), or a mixture of PCDATA and elements. The allowable contents of an element are its content model. PCDATA really means any character string that does not contain elements. PCDATA is what the bulk of elements will use between their start and end-tags. CDATA is different in that it is a method for adding any character data that should not be processed. For example, you could add some JavaScript code instructions using a CDATA section. A CDATA section tells the parser not to look for any markup until after it locates the end of the CDATA section.
Element Attributes
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>
- <BEGIN restrict="1"> 1999-07-23 </BEGIN>
</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.
Element Names
Each element has a unique name, referred to as the tag name. XML is case-sensitive in its processing of tag names. The 1EdTech Enterprise/LMS interoperability XML binding specification adheres to the following tag name rules:
< >All tag names will conform to the rules for element naming as given within the XML Version 1.0 specification.Names beginning in "xml" in any case or mix of cases are not permitted.The 1EdTech binding will use only upper case tag names. All element names in the 1EdTech XML binding are to be in capitals. This will allow uniform machine conversion to a single case should the need arise.Element names may not include words reserved by the XML specification. These include: DOCTYPE
ELEMENT
ATTLIST
ENTITY
· Tag names defined by the 1EdTech binding may not be redefined.XML Version 1.0 specification are included in the References section of this document.Declaring Element Contents
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.Declaring Element Attributes
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 - lang CDATA #IMPLIED >
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.
Use of Attributes
Within the 1EdTech 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 1EdTech 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> - <BEGIN restrict="1">1999-07-23</BEGIN>
</TIMEFRAME>Typical codes for this attribute may be "0" or "1". Attribute valid values would be defined by a parameter entity.
Lists
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?)>
- When instantiated in XML a repeating list of TEL elements would appear:
<PERSON>
- <TEL teltype="PREF">7607504785</TEL>
- <TEL teltype="FAX">7607503257</TEL>
</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.
Valid Character Sets
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.
Special Handling Requirements
vCard elements
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 1EdTech standard as uppercased names. Should a developer want an exact vCard encoding, it should be encoded as an extension.
XML Reserved Characters
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 MarkupAll 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 """."
"Text consists of intermingled character data and markup. Markup takes the form of start-tags, end-tags, empty-element tags, entity references, character references, comments, CDATA section delimiters, document type declarations, and processing instructions.White Space Handling
Questions arose several times throughout the 1EdTech 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 HandlingAn 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. "
"In editing XML documents, it is often convenient to use "white space" (spaces, tabs, and blank lines, denoted by the nonterminal S in this specification) to set apart the markup for greater readability. Such white space is typically not intended for inclusion in the delivered version of the document. On the other hand, "significant" white space that should be preserved in the delivered version is common, for example in poetry and source code.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 :
2.7 Tel
2.7.1 TelType
2.7.2 TelNumare 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.1Extensibility
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> - <COMMENTS>This is a test to demo extensions</COMMENTS>
</EXTENSION>
</PROPERTIES>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.
Enterprise/LMS Interoperability DTD
<!-- *************************************************************** --> <!-- Title : 1EdTech-EP01.dtd --> <!-- Description : 1EdTech Enterprise/LMS Interoperability DTD --> <!-- --> <!-- --> <!-- Revision History --> <!-- Date By Comments --> <!-- *********** *********** *************************************** --> <!-- 28 Oct,1999 Wayne Veres Initial Release of the XML Binding --> <!-- as approved at the 1EdTech 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 --> <!-- ............................................................... -->Sample Enterprise/LMS Interoperability Record
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 "1EdTech-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>References
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-19980210XML Namespaces
XML Namespace Recommendation of W3C: http://www.w3.org/TR/1999/REC-xml-names-19990114Addendum
Changes to the v1.0 of the 1EdTech 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 ' transaction (1|2|3) "1"'>
Should be replaced with< !ENTITY % I_Recstatus ' recstatus (1|2|3) "1"'>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 " imgtype CDATA #REQUIRED ">
Should be replaced with<!ENTITY % I_Img " imgtype CDATA #IMPLIED">
Type of Problem Technical Error Date December 14, 1999 Problem Description Inconsistency between the Information Model and the DTD
No lang attribute for element DESCRIPTIONReferences 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?) <!ATTLIST DESCRIPTION lang CDATA #IMPLIED >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 ORGNAMEReferences 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 relationReferences in Document Enterprise/LMS Interoperability DTD p. 9 Solution Proposed by the Submitter 5)The following lines should be changed: <!ENTITY % I_Relation ' myrelationship (1|2|3) "1"'>
Should be replaced with<!ENTITY % I_Relation ' relation (1|2|3) "1"'>
Type of Problem Technical Error Date December 14, 1999 Problem Description Inconsistency between the Information Model and the DTD
No longer usedReferences in Document Enterprise/LMS Interoperability DTD p. 10 Solution Proposed by the Submitter 6)Delete the following lines <!-- ............................................................... --> <!-- An enumerated vocabulary: --> <!-- 1 = PERSON object --> <!-- 2 = GROUP object --> <!-- ............................................................... --> <!ENTITY % I_IDtype ' idtype (1|2) "1"'>
Type of Problem Technical Error Date December 14, 1999 Problem Description Inconsistency between the Information Model and the DTD
No longer usedReferences in Document Enterprise/LMS Interoperability DTD p. 24 Solution Proposed by the Submitter 7)Delete the following lines <!ATTLIST IDTYPE %I_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 (SUBROLE?,STATUS,USERID?,COMMENTS?,TIMEFRAME?,FINALRESULT?,EMAIL?,EXTENSION?)>
Should be replaced with<!ELEMENT ROLE (SUBROLE?,STATUS,USERID?,COMMENTS?,DATE?, TIMEFRAME?,FINALRESULT?,EMAIL?,EXTENSION?)>
Type of Problem Technical Error Date December 14, 1999 Problem Description Inconsistency between the Information Model and the DTD
Add element DATEReferences in Document Enterprise/LMS Interoperability DTD p. 25 Solution Proposed by the Submitter 9)Add the following lines : <!-- ............................................................... --> <!-- Explanation : --> <!-- Date the current membership was established --> <!-- Type : --> <!-- --> <!-- Notes : --> <!-- ISO 8601 --> <!-- ............................................................... --> <!ELEMENT DATE (#PCDATA) >
Type of Problem Technical Error Date December 14, 1999 Problem Description Inconsistency between the Information Model and the DTD
Rename listrange to valuetypeReferences in Document Enterprise/LMS Interoperability DTD p. 9 Solution Proposed by the Submitter 10)The following lines should be changed: <!ENTITY % I_Value ' listrange (0|1) "0"'>
Should be replaced with<!ENTITY % I_Value ' valuetype (0|1) "0"'>
Type of Problem Technical Error Date December 14, 1999 Problem Description Inconsistency between the Information Model and the DTD
Make SCHEME optionalReferences 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 repeatingReferences 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?, ENROLLCONTROL?,EMAIL?,URL?,RELATIONSHIP*,EXTENSION?) >
Should be replaced with<!ELEMENT GROUP (SOURCEDID,GROUPTYPE*,DESCRIPTION,ORG?,TIMEFRAME?, ENROLLCONTROL?,EMAIL?,URL?,RELATIONSHIP*,EXTENSION?) >
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?, PHOTO?, EXTENSION?)>
Should be replaced with<!ELEMENT PERSON (SOURCEDID,USERID?,NAME,DEMOGRAPHICS?,EMAIL?,TEL*,ADR?,PHOTO?, DATASOURCE?,EXTENSION?)>
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?, ENROLLCONTROL?,EMAIL?,URL?,RELATIONSHIP*,EXTENSION?) >
Should be replaced with<!ELEMENT GROUP (SOURCEDID,GROUPTYPE*,DESCRIPTION+,ORG?,TIMEFRAME?, ENROLLCONTROL?,EMAIL?,URL?, RELATIONSHIP*,DATASOURCE?,EXTENSION?) >
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?, TIMEFRAME?,FINALRESULT?,EMAIL?,EXTENSION?) >
Should be replaced with<!ELEMENT ROLE (SUBROLE?,STATUS,USERID?,COMMENTS?,DATE?,TIMEFRAME?,FINALRESULT?,EMAIL?, DATASOURCE?,EXTENSION?) >
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 XMLReferences 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 :
2.7 Tel
2.7.1 TelType
2.7.2 TelNumare implemented in XML as
<TEL teltype="PREF">7607504785</TEL>
<TEL teltype="FAX">760750325</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.1Type of Problem Technical Error Date December 14, 1999 Problem Description Inconsistency between the Information Model and the DTD
Attribute was spelled incorrectlyReferences 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> <TEL tel.type="FAX">7607503257</TEL>
Should be replaced with<TEL teltype="PREF">7607504785</TEL> <TEL teltype="FAX">7607503257</TEL>
Type of Problem Technical Error Date December 14, 1999 Problem Description Inconsistency in element name.
Rename ORGNAM to ORGNAMEReferences 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)<
About this Document
Title 1EdTech 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 1EdTech. Document Location sites/default/files/enterprise/enbind03.pdf 1EdTech Consortium, Inc. (“1EdTech”) is publishing the information contained in this 1EdTech Enterprise XML Binding (“Specification”) for purposes of scientific, experimental, and scholarly collaboration only.
1EdTech 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 would appreciate receiving your comments and suggestions.
Please contact 1EdTech through our website at http://www.imsproject.org
Please refer to Document Name: 1EdTech Enterprise XML Binding v1.01 Revision: December 1999
