ࡱ > v : : \: ]: ^: _: `: a: b: c: d: e: f: g: h: i: j: k: l: m: n: o: p: q: r: s: t: u: v: w: x: y: z: {: |: }: ~: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : - 1# bjbj=@=@ :\, _*d_*d- } | | 8
8 tu ? " M 5 5 5 * / / / / / / / $ B D P / b " / 5 5 - ? H H H J 5 5 / H / H H " V% 5 ,mb l # / ? 0 ? # E | E 4 V% V% E % H / / H ? E |
:
Implementation Guide
for the
Postsecondary Electronic Standards Council
XML Standard Format
of the
College Transcript
Version 1.8.0
November 2017
PESC 2017. All Rights Reserved.
This document may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation my be prepared, copied, published and distributed, in whole or in part, without restriction of anyt kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. This document itself, however, may not be modified in any way except when expressly approved by PESC for purposes of developing standards and specifications.
Send corrections, comments and requests for the IG in MS Word format to:
info@PESC.org
Table of Contents
Page Topic PAGEREF Introduction \h 4Introduction PAGEREF Organization \h 4Organization and Format PAGEREF Develpment \h 9Development History and Acknowledgments PAGEREF Acknowledgment \h 11Transcript Acknowledgment PAGEREF Versions \h 11About Versions PAGEREF CollegeTranscript \h 12CollegeTranscript PAGEREF TransmissionData \h 13TransmissionData PAGEREF Source \h 15 Source PAGEREF SourceOrganization \h 17Organization PAGEREF SourceOrganizationLocal \h 20LocalOrganizationID PAGEREF SourceOrganizationContacts \h 22Contacts PAGEREF SourceOrganizationAddress \h 23Address PAGEREF SourceOrganizationPhone \h 26Phone PAGEREF SourceOrganizationFax \h 27FaxPhone PAGEREF SourceOrganizationEmail \h 28Email PAGEREF SourceOrganizationURL \h 29URL PAGEREF SourceOrganizationAccreditation \h 30Accreditation PAGEREF Destination \h 31Destination PAGEREF DestinationOrganization \h 32Organization PAGEREF DestinationOrganizationLocal \h 35LocalOrganizationID PAGEREF DestinationOrganizationContacts \h 36Contacts PAGEREF DestinationOrganizationAddress \h 37Address PAGEREF DestinationOrganizationPhone \h 40Phone PAGEREF DestinationOrganizationFax \h 41FaxPhone PAGEREF DestinationOrganizationEmail \h 43Email PAGEREF DestinationOrganizationURL \h 43URL PAGEREF Student \h 44Student PAGEREF StudentPerson \h 46Person PAGEREF StudentPersonAgencyIdentifier \h 49AgencyIdentifier PAGEREF StudentPersonBirth \h 51Birth PAGEREF StudentPersonName \h 52Name PAGEREF StudentPersonAlternateName \h 54AlternateName PAGEREF StudentPersonHighSchool \h 57HighSchool PAGEREF StudentPersonContacts \h 60Contacts PAGEREF StudentPersonContactsAddress \h 61Address PAGEREF StudentPersonContactsPhone \h 64Phone PAGEREF StudentPersonContactsFax \h 66FaxPhone PAGEREF StudentPersonContactsEmail \h 68Email PAGEREF StudentPersonContactsURL \h 69URL PAGEREF StudentPersonGender \h 69Gender PAGEREF StudentPersonResidency \h 71Residency PAGEREF StudentPersonDeceased \h 72Deceased PAGEREF StudentPersonLanguage \h 73Language PAGEREF StudentAcademicRecord \h 75AcademicRecord PAGEREF StudentAcademicRecordSchool \h 77School PAGEREF StudentAcademicRecordSchoolLocalOrg \h 81LocalOrganizationID PAGEREF StudentAcademicRecordSchoolContacts \h 82Contacts PAGEREF StudentAcademicRecordSchoolContactsAddr \h 83Address PAGEREF StudentAcademicRecordSchoolContactsPhone \h 86Phone PAGEREF StudentAcademicRecordSchoolContactsFax \h 87FaxPhone PAGEREF StudentAcademicRecordSchoolContactsEmail \h 90Email PAGEREF StudentAcademicRecordSchoolContactsURL \h 90URL PAGEREF StudentAcademicRecordStudentLevel \h 91StudentLevel PAGEREF StudentAcademicRecordAcademicAward \h 93AcademicAward PAGEREF StudentAcademicRecordAcademicAwardHonors \h 96AcademicHonors PAGEREF StudentAcademicRecordAcademicAwardProgra \h 97AcademicAwardProgram PAGEREF StudentAcademicRecordAcademicAwardSummar \h 99ProgramSummary PAGEREF StudentAcademicRecordAcademicAwardGPA \h 104GPA PAGEREF StudentAcademicRecordAcademicAwardPHonor \h 106AcademicHonors PAGEREF StudentAcademicRecordAcademicAwardDegReg \h 107AcademicDegreeRequirement PAGEREF AcademicAwardAcademicSummary \h 108AcademicSummary PAGEREF AcademicAwardAcademicSummaryGPA \h 112GPA PAGEREF AcademicAwardAcademicSummaryHonors \h 114AcademicHonors PAGEREF AcademicAwardAcademicSummaryProgram \h 115AcademicProgram PAGEREF AcademicSummary \h 118AcademicSummary PAGEREF AcademicSummaryGPA \h 123GPA PAGEREF AcademicSummaryHonors \h 125AcademicHonors PAGEREF AcademicSummaryProgram \h 126AcademicProgram PAGEREF AcademicSession \h 128AcademicSession PAGEREF AcademicSessionDetail \h 130AcademicSessionDetail PAGEREF AcademicSessionSchool \h 133School PAGEREF AcademicSessionSchoolLocal \h 137LocalOrganizationID PAGEREF AcademicSessionStudentLevel \h 137StudentLevel PAGEREF AcademicSessionProgram \h 139AcademicProgram PAGEREF AcademicSessionAward \h 141AcademicAward PAGEREF AcademicSessionCourse \h 144Course PAGEREF AcademicSessionCourseSupplemental \h 157CourseSupplementalAcademicGrade PAGEREF AcademicSessionCourseSupplementalGrade \h 158CourseSupplementalGrade PAGEREF AcademicSessionCourseOverrideSchool \h 161CourseOverrideSchool PAGEREF AcademicSessionCourseOverrideSchoolLocal \h 165LocalOrganizationID PAGEREF AcademicSessionCourseRequirement \h 166Requirement PAGEREF AcademicSessionCourseAttribute \h 167Attribute PAGEREF AcademicSessionCourseProficiency \h 169Proficiency PAGEREF AcademicSessionCourseLicensure \h 170Licensure PAGEREF AcademicSessionCourseLanguage \h 171LanguageOfInstruction PAGEREF AcademicSessionSummary \h 172AcademicSummary PAGEREF AcademicSessionSummaryGPA \h 177GPA PAGEREF AcademicSessionSummaryHonors \h 179AcademicHonors PAGEREF AcademicSessionSummaryProgram \h 180AcademicProgram REF Course \h \* MERGEFORMAT REF Course \h \* MERGEFORMAT PAGEREF Course \h 182Course PAGEREF CourseCourseSupplementalAcademicGrade \h 195CourseSupplementalAcademicGrade PAGEREF CourseCourseSupplementalAcademicGradeGra \h 196CourseSupplementalGrade PAGEREF CourseOverrideSchool \h 198CourseOverrideSchool PAGEREF CourseOverrideSchoolLocalID \h 204LocalOrganizationID PAGEREF CourseRequirement \h 205Requirement PAGEREF CourseAttribute \h 206Attribute PAGEREF CourseProficiency \h 208Proficiency PAGEREF CourseLicensure \h 209Licensure PAGEREF CourseLanguageOfInstruction \h 210LanguageOfInstruction PAGEREF AdditionalAcademicStudentAchievements \h 211 AdditionalStudentAchievements PAGEREF AdditionalStudentAchievementsRequirement \h 213 Requirement PAGEREF AdditionalStudentAchievementsAttribute \h 215 Attribute PAGEREF AdditionalStudentAchievementsProficiency \h 216 Proficiency PAGEREF AdditionalStudentAchievementsLanguage \h 217 Language PAGEREF AdditionalStudentAchievementsLicensure \h 220 Licensure PAGEREF Health \h 220Health PAGEREF HealthImmunizations \h 221 Immunizations PAGEREF Tests \h 223 Tests PAGEREF TestsStudentLevel \h 225 StudentLevel PAGEREF TestsSubtest \h 226 Subtest PAGEREF TestsSubtestTestScores \h 227 TestScores PAGEREF AppendixA \h 229 Appendix A: State and Province Codes PAGEREF AppendixB1 \h 230 Appendix B: Country Codes PAGEREF AppendixC1 \h 236Appendix C: Language Codes (ISO) PAGEREF AppendixD \h 246 Appendix D: TestCode and TestName PAGEREF AppendixE \h 251 Appendix E: SubtestCode and SubtestName PAGEREF AppendixF \h 254 Appendix F: Course Academic Grade Scale Codes REF AppendixG \h PAGEREF AppendixG \h 260 Appendix G: Sample XML College Transcript Version 1.6.0 PAGEREF AppendixH \h 273Appendix H: Changes to this Version of the Implementation Guide
Introduction
For the higher education community to achieve the timely, uniform, accurate, and secure exchange of the academic records for current and previous postsecondary students, the Postsecondary Electronic Standards Council (PESC) developed and obtained approval for a standard format in eXtensible Markup Language (XML) for the College Transcript. This Implementation Guide describes the approved format for electronically exchangeable postsecondary school records and can help non-technical users to implement the electronic records exchange process.
Besides its obvious use for postsecondary educational institutions, this Guide should also be useful for software vendors and state and federal education agencies.
Postsecondary educational institutions use student transcripts to transmit current and historical student academic records to postsecondary educational institutions and to other education agencies. When a postsecondary student intends to transfer to another postsecondary school, it is essential that the students academic record be made available to the receiving school as quickly as possible so that the receiving institution can make faster admissions and placement decisions. In addition, the prompt transmission of the students academic record allows the receiving institution to evaluate the record in a more timely fashion and thereby to advise the student on the applicability of past courses to current program requirements.
The postsecondary student transcript contains personal history and identifying information about the student, the current academic status, dates of attendance, courses completed with grades earned, diplomas and certificates awarded, and selected test scores.
This Implementation Guide is based on the Approved PESC XML College Transcript Schema version 1.8.0. It was officially approved and released in November 2017. It uses the Academic Record Sector Library Version 1.13.0 and Core Main Version 1.19.0. For the electronic exchange of these student records to be completely automated, it is essential that all users adhere strictly to the requirements of this Schema, and understand and comply with the requirements outlined in this Guide. Although not required in the Schema, this Implementation Guide also makes recommendations for acceptable practice based on The Academic Record and Transcript Guide, a publication by the American Association of Collegiate Registrars and Admissions Officers (AACRAO).
Organization and Format
The schema for the College Transcript is made up of four main parts:
Transmission Data
Student
Note Message
User Defined Extensions
However, three of these main parts branch to form other parts, which in turn branch out further. This Guide is organized so that each level of branching is documented in the order as follows:
Transmission Data Level I
Sub-level IA
Sub-level IA1
Sub-level IA1a
Sub-level IA1b
Sub-level IA2
Sub-level IA2a
Sub-level IA2b
Sub-level IB
Sub-level IB1
Sub-level IB1a
Student Data Level I
(Etc.)
The heading for each level and sub-level indicates the position of the subsequent diagram in the larger Schema.
Following the heading, the diagram serves to illustrate its relationship with the preceding branch. All diagrams in this Guide were copied from a graphical representation of the College Transcript Schema using a software package from Altova Corporation called XMLSpy.
Example:
The boxes in the diagrams can illustrate two separate components of the Schema. First, certain boxes show complex data element groupings, which branch out to form lower-level data element groupings. Other boxes show the Schemas other primary component, the simple data element fields that contain actual data. A box with a solid border indicates that that particular data element or field is required. A box with a dotted line border indicates an optional data element or field. Likewise, a solid line connecting two or more boxes indicates that the boxes to the right in the diagram are required fields and a dotted line indicates the fields in the boxes to the right are optional. A plus (+) sign at the right of a box indicates that the element grouping or field branches beyond the scope of a given diagram. The Schema (and this Guide) displays such branching in subsequent diagrams.
Each diagram includes a representation of a field or data elements repeatability. Under a given box, for example, 0... " w o u l d i n d i c a t e a n o p t i o n a l d a t a e l e m e n t o r f i e l d ( w i t h a m i n i m u m n u m b e r o f o c c u r r e n c e s o f z e r o ) t h a t c a n b e r e p e a t e d a n i n f i n i t e n u m b e r o f t i m e s . O n t h e o t h e r h a n d , 1 . . . 3 w o u l d i n d i c a t e a m a n d a t o r y f i e l d ( w i t h a t l e a s t o n e r e q u i r e d i n s t a n c e ) t h a t c a n be repeated up to 3 times.
Although most data elements that could theoretically be included an infinite number of times in the schema, would typically only be included once or perhaps a few times. Including a high number of occurrences of a field would present processing problems for the receiving agency or institution.
Under each diagram, a table will appear with five columns:
Tag Name: This is the name of the data element grouping or field that will appear in the Schema and in the instance document. (Instance document refers to a transcript with real data for an actual student that institutions would exchange.) The format for the tag name is Upper Camel Case which takes a name such as Transmission Data and eliminates the space between the two words, retaining the capital letters of each word making up the tag name.
Schema Use: This column indicates whether the data element or field is required or optional in the instance document. If a required field is not included in the instance document, the transcript will normally be rejected by the receiving institution or agencys computer program (XML Parser). This column will also include a notation (Repeatable) if a data element (field) can be sent multiple times.
Description: This is a brief description of the data included with a particular XML tag name. The description normally comes from the description in the Core Main Schema for data elements.
Recommended Use: This column reflects recommendations from the developers of the College Transcript Schema, standards of good practice as defined by the AACRAO Transcript Guide, and generally recommended practices for exchanging electronic transcripts. Reaching consensus on the recommended use of data elements and fields has grown into an additional task for the PESC Education Record User Group (ERUG).
Recommendations in this column generally match the standards in Schema Use, especially if Schema Use shows an element or field as Required. However, a component listed as Optional under Schema Use may be listed as Recommended in Recommended Use if the Workgroup or ERUG regards the element or field as essential and in keeping with good practices in the AACRAO community.
Required: Indicates that a sending institution must include the data element or field in its transmission since it is required by most schema parsers.
Recommended: If the information for a field is readily available at the sending school, then Recommended indicates that the field should be sent.
Conditional: This recommended use does not occur often in this Guide, but it may occur when the recommendation (recommended, optional or not recommended) is dependent on another data element being sent, or even on the value of another data element that is sent.
Optional: Indicates that it is generally up to the sender to include the data or not. If a paper transcript normally includes the element or field, then the sender will probably choose to include it. In addition, within certain states, items marked as Optional may be essential for intrastate exchanges. Finally, it may be the case that a destination school receives all data at a single location; in such a case, the sender may need to provide optional elements to identify the specific intended recipient.
Not Recommended: Indicates that, in the view of the Workgroup or the ERUG, such a data element or field should not form part of a transmission. In general, the Workgroup recommends that institutions not send notes or comments, since most Student Information System programs cannot automatically process them. Sending these elements could thereby slow or impede automatic processing by the receiving school. However, exceptions to this rule-of-thumb may lie in the needs of individual states, as certain intrastate transmissions may require information that only a note or comment field can accommodate. In such cases, the Workgroup recommends that institutions in the state develop a protocol for maintaining and transmitting the element or field. In other cases, common practice may be to include data that is not recommended by the Workgroup or ERUG.
In many cases, because of the reusability of complex data elements in XML, there are data elements included in this schema that may not be appropriate for use in the College Transcript. In these cases, the recommended use may be designated as Not Recommended.
Format: This column shows the minimum and maximum number of occurrences of the data element. It also shows the minimum and maximum length allowable for a field, if that field does not have enumerated values and is not a special type of field, such a date field.
minOcc 1 indicates a required field, since it must have at least one occurrence in the instance document. minOcc 0 indicates an optional field.
maxOcc followed by a number or symbol specifies the maximum number of times that an element can recur in an instance document at a particular position. For example, maxOcc 5 would indicate that the field may occur no more than 5 times in a gi v e n p o s i t i o n o f t h e i n s t a n c e d o c u m e n t . m a x O c c " i n d i c a t e s t h a t a f i e l d m a y r e c u r a n u n l i m i t e d n u m b e r o f t i m e s i n t h e i n s t a n c e d o c u m e n t . H o w e v e r , t h e u s e o f a n e x c e s s i v e n u m b e r o f o c c u r r e n c e s p u t s a b u r d e n o n t h e r e c e i v i n g a g e n c y o r i n s t i t u t i o n , s o t h e y should always be limited to the fewest number possible.
minLength indicates the minimum number of characters that a field must contain, while maxLength indicates the maximum number of characters that a field may contain.
Enumerations is used to list the allowable values that may be used in the instance document. They must be used exactly as shown in this column. When the values are enumerated in this column, minLength and maxLength will not be indicated and are not appropriate.
DateTime always uses the same format: ccyy-mm-ddThh:ii:ss(+GMT). An example would be 2005-11-20T08:15:36(+7). Likewise, Date always uses the format ccyy-mm-dd. An example would be 2005-11-20. If either DateTime or Date is used, then minLength and maxLength will not be indicated.
xs:decimal indicates a numeric field. It has a maximum length of 18 characters including a decimal if the decimal point is explicitly included. Typical values would be (1) a grade point average of 3.250; (2) credits earned of 24; or (3) credits included in GPA of 16.
minInclusive indicates the lowest value of a decimal type field that can be included, while maxInclusive indicates the maximum value that can be included in a decimal type field.
totalDigits indicates the maximum number of digits that can be used in the specified field.
xs:date is the format for a date. In XML, it would be included as ccyy-mm-dd. For example, the date October 28, 2009 would appear in the instance document as 2009-10-28.
xs:gMonthDay is the format for a date without including the year. The format in the instance document would be mm-dd which is mm-dd preceded by two dashes.
xs:gYearMonth is the format for a date without the exact day of the month. The format would be ccyy-mm.
Comments: The Guide may include comments beneath the rows of a given table and/or at the end of the table. The Workgroup or ERUG intends for these comments to provide further explanation for the items displayed above the comment. Comments refer to the row immediately above the comment row, except for a comment at the end of a table. In this case, the comment typically refers to the entire table
Code Illustration: Below each table, the Guide includes a snippet of what that portion of an instance document might look like in XML format. If the data element is a required data element for the schema, then that data element will be in bold type in this Guide.
If the code is illustrating a complex data element that will be further explained on a subsequent page, then only the opening and closing tags will be included. For example:
If the code is illustrating a simple data element that is not recommended for inclusion, then an empty tag may be included for this particular Code Illustration. For example:
Appendix L shows an example of an XML instance document for a college transcript. This example is not intended to match the Code Illustrations throughout the Guide, since a typical transcript would not include many of the optional sections of the Schema.
Order of Including Data Elements: Although the Schema includes many optional data elements and you may choose not to include them in an instance document, if you do include data elements, they must appear in the same order they appear in the Schema.
NoteMessage: You will find NoteMessage appearing throughout the Schema. This Guide almost always recommends against the routine use of note messages. Unless there is a previously agreed upon format for a note message between the sender and the receiver, notes cannot be interpreted and automatically processed by the receivers computer. Although not required by the schema, it is strongly recommended, for example, that if the note message is only appropriate for schools in a given state or province, that the first two digits of the text of the note message be the two digit code for that state or province. That will allow recipient schools or agencies in a state or province to query these two digits and immediately ignore it, if it refers to another state or province.
UserDefinedExtensions: The user-defined extension (UDE) design pattern is intended to address situations in which the current Schema does not accommodate sender-specific data. The Schema has to allow for additional elements that may be defined and used at a later date. The user-defined extensions pattern serves as a placeholder for these to-be-defined fields and elements. However, it can require that these fields be defined in a Schema by the organization that wants to use the extensions area. Senders should take care not to use the user-defined extensions as a fall-back for doing appropriate research and design. They should only use the extension when in actuality, the organization defining the base Schema cannot define the additional elements that other organizations may need. Furthermore, other recipients not interested in the data these specific organizations want to exchange in the user-defined area, may then just ignore the UDE.
In general, the use of NoteMessage is recommended to exchange smaller, uncomplicated data pertaining to a state or province or region, while UserDefinedExtensions should be reserved for much more complicated amounts of structured data.
User-defined extensions are beneficial when both the sending and receiving institutions agree on their use. For best work practice, the Workgroup recommends the use of user-defined extensions in the following scope:
Mutually defined sub-schemas: For the transmittal and receipt of data agreed upon by both sending and receiving institutions;
State systems: In the California CSU system, this might be the General Education requirements; For the University of California system, this would be the UC requirements; R e g i o n a l r e q u i r e m e n t s
T h e b e n e f i t o f u s i n g t h e u s e r - d e f i n e d e x t e n s i o n s s t e m s p r i m a r i l y f r o m t h e o p e n n a t u r e o f t h e X M L d e s i g n . I n s t i t u t i o n s m a y t a k e a d v a n t a g e o f X M L s o p e n n e s s , u s e t h e u s e r - d e f i n e d e x t e n s i o n s t o a c c o m m o d a t e d a t a f o r w h i c h t h e o r i g i n al Schema has not accounted, and standardize the use of the extensions among themselves. Such institution-to-institution agreements allow for the following:
Strict standardization among institutions through design and implementation agreements,
Ability of users outside of the agreement to ignore the data contained in the user-defined extensions.
Because the Schema recommends that institutions develop their own agreements for the use of user-defined extensions, the Workgroup also recommends against the development of national UDE standards.
Example Code:
20042
ENG
0114
02
When you build a UDE, you will need to build it into a separate local dictionary that is specific to your instance usage. This dictionary must be added to the instance document header as a reference. Once this is done you will need to build the simple elements into this dictionary and then you can pass the actual values via your schema. This should allow for accurate processing and validation. Adding elements to the schema but not having the definition referenced in any dictionary creates a validation rule. Since they are User Defined Extensions, it is not advisable to modify the Core or Sector dictionaries but create a local UDE dictionary that you can use to trade with those that will require it in order to process your UDE correctly
Please reference Excerpt from PESC Guidelines for XML Architecture and Data Modeling page 47 HYPERLINK "http://www.pesc.org/interior.php?page_id=143" \h ( HYPERLINK "http://www.pesc.org/interior.php?page_id=143" \h http://www.pesc.org/interior.php?page_id=143 HYPERLINK "http://www.pesc.org/interior.php?page_id=143" \h ) for a full explanation on the usage of user-defined extensions.
Development History and Acknowledgments
The American Association of Collegiate Registrars and Admissions Officers (AACRAO) Committee on the Standardization of Postsecondary Education Electronic Data Exchange (SPEEDE) began working on a national standard format for the electronic exchange of postsecondary student records in 1989. Initially the work of the committee was funded by AACRAO. At about the same time, the US Department of Educations National Center for Education Statistics (NCES) began developing a national standard format for the electronic exchange of student records for kindergarten through high school students. The K12 community was primarily represented by the Council of Chief State School Officers (CCSSO). To gain more credibility in the creation and widespread adoption of the standards, the two groups (AACRAO and NCES) approached the American National Standards Institutes (ANSI) Accredited Standards Committee (ASC) X12 for assistance in developing and approving the two standard formats.
ASC X12 reviewed the two proposals and insisted that only one standard be developed and approved. That standard would be the Kindergarten through Postsecondary Education Student Record. At that time, NCES decided to fund the travel of the AACRAO SPEEDE Committee as well as those working on the K-12 standard. The ASC X12 Standard in the Electronic Data Interchange (EDI) format was approved in the early 1990's as ANSI ASC X12 Transaction Set 130 for the Student Educational Record (Transcript).
During this time period (before the Internet was widely available), the format stressed the transmission of as much data as possible using the fewest characters. This emphasis emerged because transmission costs were based on the number of characters or bytes being sent over the Value Added Electronic Networks (VANs).
The ANSI ASC X12 Standard is now in use by a significant number of postsecondary institutions in the United States and Canada. Over 1,000,000 transcripts (mostly postsecondary) are exchanged electronically in the EDI format through the University of Texas at Austin SPEEDE Server in the ASC X12 EDI format each year. The UT Austin SPEEDE Server is a free server and is maintained, at no charge to users, by the staff at the University of Texas at Austin. In addition, the state of Florida maintains a server operated by the Florida Information Resource Network (FIRN). FIRN processes over 750,000 high school and college transcripts each year in its proprietary format, but reformats them in the ANSI ASC X12 TS130 format for exchanges out of the state. Texas, Iowa and Maryland also have significant electronic exchanges of student transcripts.
The number of transcripts exchanged electronically in the ASC X12 EDI format continues to grow significantly. However, the education community felt that an alternative format should be explored. In the view of many, the perceived complexity of implementing the EDI standards was one of the reasons that many schools did not use the EDI format.
The Postsecondary Electronic Standards Council (PESC) commissioned this exploration by creating the XML Forum. The Forum had as its primary purpose to determine if an XML format might result in significantly increased electronic exchange of students education records.
The wide and inexpensive availability of XML software tools and the already existing and pervasive use of XML by many schools information technology staffs made the XML process appear to have a much better chance of rapid acceptance and implementation by postsecondary educational institutions.
The early efforts of the XML Forum emphasized the creation of standard reusable core components. Once the Forum made significant progress with this work, PESC agreed to develop an XML Standard Format for the College Transcript to demonstrate that this could be done.
Bruce Marton from the University of Texas at Austin headed this effort and received the bulk of his support from the AACRAO SPEEDE Committee that had developed the earlier EDI standard.
PESC approved the XML standard for the College Transcript (Version 1.0.0) in July 2004.
Requested changes to this PESC approved schema should be submitted the the PESC Education Record User Group (ERUG) which holds regular conference calls to discuss suggested changes to this schema. Changes approved by ERUG will be submitted to the PESC Change Control Board for its approval.
Transcript Acknowledgment
A significant benefit of the electronic exchange of student transcripts over the exchange of paper documents is enhanced security. With desktop or notebook computers, readily available desktop publishing software, and inexpensive ink jet and laser printers, it is now quite easy for a student or other person to intercept a paper transcript after it is issued by the sending school, make alterations in the document, or create an entirely new paper transcript for the purported student, and forward it on the recipient school, parent, sponsor, employer or prospective employer as an official transcript. Official envelopes for the sending school can also easily be printed as can seals and official looking stamps. Policies of some schools to accept handcarried transcripts, makes this abuse even easier.
The nature of the exchange of electronic transcripts through a secure Internet server such as the free server provided by the University of Texas at Austin made security far superior to paper exchanges.
By consistent use of the PESC XML Transcript Acknowledgment Schema, this security is enhanced even more. By sending an XML Transcript Acknowledgment Instance Document back to the known electronic address of the school that is identified as the sending school of the transcript, then a security breach can be identified (if that transcript did not come from the school identified as the source of that electronic transcript).
About Versions
The first digit of the version indicates a major change to the schema. A change in the first digit indicates that the newer schema is not backwardly compatible with earlier versions. A change in the second digit indicates a minor change to the schema. A change in the second digit (and not the first digit) indicates that the newer schema is backwardly compatible with the previous version.
A minor change means that a receiving school that has upgraded to, for example, version 1.4.0 can continue to receive and process any instance document that used version 1.4.0 or earlier. However, a school still using version 1.3.0 would only be able to receive and process instance documents using version 1.4.0 if the instance document did not contain any occurrences of the new data elements, or any new values of existing data elements.
A change in the third digit only indicates a micro change from the previous schema and it is compatible with the previous version. If no change is made to the schema, but only one or more changes to the documentation, e.g., the Implementation Guide, then an alpha suffix will be used to denote a documentation change only. A list of changes made to the schema from Version 1.0.0 to this version (1.8.0) is included in Appendix M.
College Transcript
Tag Name Schema Use Description Recommended Use Format TransmissionData Required Routing and header information Required minOcc 1
maxOcc 1Comment: This complex data element will be further expanded and explained on page 2 which follows. Student Required Body of document. One segment per student Required minOcc 1
maxOcc 1Comment: This complex data element will be further expanded and explained on page 41 which follows. NoteMessage Optional
Repeatable Additional information about transcript Not re c o m m e n d e d m i n O c c 0
m a x O c c "
m i n L e n g t h 1
m a x L e n g t h 8 0 C o m m e n t : A l t h o u g h N o t e M e s s a g e o c c u r s f r e q u e n t l y t h r o u g h o u t t h i s s c h e m a a n d I m p l e m e n t a t i o n G u i d e , i t i s a l m o s t a l w a y s N o t
R e c o m m e n d e d f o r i n c l u s i o n . T h i s i s b e c a u s e i t c a n n o t n o r m a l l y b e p r o c essed automatically by the receiving schools or agencys computer system. It may be recommended in some cases where a state or agency has established structured formats so that the receiving schools or agencys computer can process it automatically.UserDefinedExtensions Optional Additional structured information. Requires mutually defined XML schema. Optional minOcc 0
maxOcc 1Comment: The College Transcript Schema can only contain information about one student. However, you can include instance documents for multiple students by using the PESC Schema for the Academic Record Batch Submittal which is available on the PESC web site at www.PESC.org.
Code illustration:
TransmissionData
Tag Name Schema Use Description Recommended Use Format DocumentID Required The File Transmission Date and Time stamp with additional unique qualifying characters Required minOcc 1
maxOcc 1
minLength 1
maxLength 35Comment: The structure of the DocumentID is up to the sender. However, the general practice is that it includes the date and time plus other identifying data. CreatedDateTime Required The Date and Time stamp when the document was created Required minOcc 1
maxOcc 1
xs:datetime ccyy-mmddThh:ii:ss{+-GMT]DocumentTypeCode Required Type and purpose of document being transmitted Required
minOcc 1
maxOcc 1
Enumerations:
Cancel
Change
InstitutionRequest
RequestedRecord
Response
ReverseTransfer
StudentRequest
TermEnroll
TermGrade
ThirdPartyRequest Comment: Change would be an appropriate value if the transcript had previously been sent and this is a corrected or updated
transcript. Institution Request would be appropriate if this transcript is being sent at the request of a postsecondary institution to which
the student has applied for admission. Term Enroll and Term Grade would not be typical values for this data element. TransmissionType Required The nature of the transmission Required minOcc 1
maxOcc 1
Enumerations:
Original
Replace
Duplicate
Resubmission
Reissue
MutuallyDefined Source Required This field is required and essential to indicate the source of the Transcript being sent. It is normally the sending school where the student enrolled for courses. Required minOcc 1
maxOcc 1Comment: This complex data element will be expanded on page 5 which follows. Destination Required This field is mandatory and essential to indicate the destination or recipient of the transcript being sent. Required minOcc 1
maxOcc 1Comment: This complex data element will be expanded on page 24 which follows. DocumentProcessCode Optional This element indicates a TEST or
PRODUCTION document Required if
TEST; PRODUCTION
implied, not
recommended minOcc 0
maxOcc 1
Enumerations:
TEST
PRODUCTION Comment: If a test transcript is being sent as part of the implementation testing process, or to identify a problem, then this data
element would be included with the value TEST. If this is not the case and this is a normal official transcript being sent, then this optional data element would not be included in the instance document. DocumentOfficialCode Optional This element indicates if the document is unofficial. Unofficial documents may be produced for reference purpose but may not be binding. Required if
Unofficial;
Official implied, not
recommended minOcc 0
maxOcc 1
Enumerations:
Official
Unofficial Comment: With paper transcripts, it is normal practice for the recipient to decide if the transcript received is to be considered official or unofficial. With electronic transcripts exchanged through a secure process such as the University of Texas at Austin SPEEDE Server, most recipients would consider them official. In some states, based on a prior agreement, some optional data elements that are not sent for official transcripts may be included in unofficial transcripts. If this is a normal official transcript being sent, then this data element would not be included in the instance document. DocumentCompleteCode Optional This element indicates whether the document conveys a complete record. Partial documents may be produced for information that is recorded in multiple media or formats. If the student is still enrolled at the school, but the record being sent includes all the available information to date for that student, then the record would be considered complete, and this data element would not be included in the transcript. A value of Partial generally means that the remainder will be sent in hard copy. Required if not Complete;
Complete
is implied, not
recommended minOcc 0
maxOcc 1
Enumerations:
Partial
Complete RequestTrackingID Optional The unique ID associated with a request action that is returned to the requestor for document matching and tracking. Optional minOcc 0
maxOcc 1
minLength 1
maxLength 35UserDefinedExtensions Optional Additional structured information. Requires mutually defined XML schema. Not
Recommended minOcc 0
maxOcc 1NoteMessage Optional
Repeatable Additional information about transmission Not recommended minOcc 0
m a x O c c "
m i n L e n g t h 1
m a x L e n g t h 8 0
C o d e i l l u s t r a t i o n :
<