XML PESC FAQs

Currently supported browsers are: Chrome: (V35 or greater), Firefox (V30 or greater), Internet Explorer (V9, 10, and 11), and Safari (V5, 6,7).

The OUAC will not support mobile browsers for AMS testing.

Yes, as per the OUAC Systems Manual, Appendix E — File Transmission & Naming Standards.

Depending on the scenario (e.g., original distribution vs. amendment distribution, etc.), optional fields not input by the applicant will either:

• be sent as empty XML tags
• not be sent in XML

We will continue to send the OUAC field lengths, which in most cases, are shorter than in PESC. Where OUAC’s are longer, we have overridden the length in the schemas. Address lines will continue to be 30 characters. Name fields (first, middle, last) will also continue to be 30 characters.

Yes, you’re correct that the field lengths are not always the same since the XML is a pre-defined North American standard. The OUAC’s data is usually shorter than PESC’s. There are a few elements (e.g., telephone numbers) where the OUAC’s is longer, which is one of the reasons we had to create the OUAC versions of the schemas.

The general rules to follow are:

1. If the data in the XML format uses a PESC-defined code value (e.g., the full-time/part-time choice attribute), then use the length from the XML schema.
2. If not, then it’s either an OUAC code (e.g., 2-digit applno) or a free-form field (e.g., Surname) and the Systems Manual supersedes the PESC definition.The XML format is using the min/max length constructs, as opposed to OUAC flat file, which generally uses fixed length with leading/trailing blanks.

This question relates to the following code:

1<Citizenship>
2<CitizenshipStatusCode>NonCitizen</CitizenshipStatusCode>
3<CitizenshipCountryCode>CA</CitizenshipCountryCode>
4</Citizenship>
5<Citizenship>
6<CitizenshipCountryCode>DO</CitizenshipCountryCode>
7</Citizenship>>

Yes, that is correct. Also, the country code in line 3 will always be ‘CA’ for Canada, as the corresponding status in line 2 represents OUAC Element 220 IMSTAT.

This question relates to the following code:

1<Citizenship>
2<CitizenshipStatusCode>NonCitizen</CitizenshipStatusCode>
3<CitizenshipCountryCode>CA</CitizenshipCountryCode>
4</Citizenship>
5<Citizenship>
6<CitizenshipCountryCode>DO</CitizenshipCountryCode>
7</Citizenship>>

Yes, that is correct.

No. PESC uses the ISO 3166-1 alpha-2 standard enumerated codes, which is a list inside the XSDs used to validate the XML documents.

The ISO enumeration list is periodically updated by ISO, so it may not always be in synch with the XSD — this will be an ongoing maintenance item (as it is currently for OUAC’s 5-digit country code). The ISO enumeration list is also in the OUAC mapping spreadsheet (tab CountryCode) and will eventually be available in the CUNTRYP.TXT admin table once that has been generated.

Name Type is a key in the record structure that allows all types of names to be housed in the same record. When the OUAC uses that field to generate the outbound XML file, it triggers the corresponding XML tag name (e.g., <Name> versus <AlternateName>).

Name Code is the actual data value which will be in the XML tag <NameCode>.These do not have their own data elements in the Systems Manual, but the structure implied by item 1 are shown within each of the applicant’s name-related fields (e.g., Element 040 SURNAM, Element 055 CUNAME, etc)

No, the tag names will not contain OUAC-specific items. PESC has set the standard XML tag names and we will not be changing them. Those will appear however, as codified data between the start and end tags in one of the following 2 ways:

1. As a prefix in the plain text content of a NoteMessage XML element to assist automated processing of these note fields.
   Example: The value ‘1’ for the OUAC Element 527, Prior Institution Sequence Number, will be sent as <NoteMessage>Elem527:1</NoteMessage>
2. As a question ID in the PESC “ApplicationQuestion” element
   Example: The code value ‘1’ for the OUAC Element 411, Year Desired, will be sent as:<ApplicationQuestion>
   <QuestionTitle>Year Desired</QuestionTitle>
   <QuestionID>411</QuestionID>
   <AnswerText>1</AnswerText>
   </ApplicationQuestion>

Yes, for transcripts, that is correct. That element in the high school transcript is only used for the OUAC’s 12-digit prior institution code, which is only sent on the CEGEP and BC high school transcripts (for 105 only). Element 528 is also distributed as part of the Academic Background (Prior Institution) Details, providing OUAC’s code along with the textual description of the institutions reported by the applicant.

Yes, Elem#### prefixes all NoteMessage data transmissions.

Note: Some NoteMessage values are constants that are meant to act as additional descriptors to help you know which occurrence of a tag to use if that tag can repeat. In some cases, (e.g., much of the GPA-related information) 1 NoteMessage actually describes the content of several other tags, each containing a different OUAC data element.

The definition of the Course XML complex element is consistent in both of the locations you mentioned, so we wanted to keep the distro record definitions consistent as well (i.e., only adding the additional keys for the Course within Session).

You are right that there are some fields that will only be used sometimes (e.g., by the CEGEP transcript, but not by BC or Ontario). This keeps the options open for the future growth of electronic transcripts with minimal change to the distro staging records. Several other Canadian provinces are currently working on their XML high school transcripts (which we could work on receiving from them in future), and may potentially use any of the defined tags.

The “DistributionID” is sent at the applicant transmission data level to tie the data for each XML AdmissionsApplication to the file it was received in:
a) for universities who will receive the “batch” XML file (which can be parsed into individual XML applicant files ); or
b) for universities who will receive the “zip” file containing the individual XML files. It’s also used in the distro staging tables as a high-level key. Our plan is that the current file names for the “Other Documents” will still contain the distribution number.

For example, if there are 70 applicant files for 101 today, all 70 files will have the same distribution ID (e.g. 100). Then tomorrow, if there are 50 applicant files, all 50 files will have the +1 distribution ID (i.e., 101)

This is a 2 part answer, as it depends on the context of the tag:

1. If the OUAC data element being represented by a particular occurrence of SessionDesignator does not have a month (e.g., tag PreviousApplication.SessionDesignator for OUAC Element 430, Previous Application Year), then yes, please ignore the month. The PESC XML format is YYYY-MM, so we have to append a constant.
2. If no OUAC data element is actually being represented by a particular occurrence of SessionDesignator (e.g., tag ApplicationSession.SessionDesignator is a mandatory tag and has to be used to allow the use of ApplicationSession.SessionName for OUAC Element 400, Expected Enrolment Date), then please ignore SessionDesignator altogether.

The makeup of the number is:
Format: yyyyeeeeeeeeeeeiiiiiccccaaa, where:
yyyy = OUAC Admissions cycle
eeeeeeeeeee = OUAC PeopleSoft “EMPLID” (Element 3380)
iiiii = OUAC PeopleSoft institution code (constant “GUELP” for Univ of Guelph)
cccc = OUAC PeopleSoft Career code (either UGRD or GRAD for Guelph)
aaa = OUAC PeopleSoft Admit type code (Element 3385)

No. The reason is that PESC had defined XML tags and codes to represent all of our values for Elements 585 and 586 except for “delete”, which fits into the action= attribute we’ve added.

Yes, this is correct.

However, it is a different indicator which will be sent as “true” and a different NoteMessage. In the case of deceased, it’s:
Applicant.UserDefinedExtensions.OUACExtensions.Deceased.DeceasedIndicator = ‘true’
Applicant.UserDefinedExtensions.OUACExtensions.Deceased.NoteMessage = ‘DECSED’

Yes, that’s correct.

You can distinguish 1 collection period from the other using the dependent tag “GPA.NoteMessage”, which will have these 4 values for the Ontario HS transcript:
Elem3030:Application
Elem3030:February
Elem3030:May
Elem3030:July

Note: One small difference for July is the tag CreditHoursEarned is used instead of CreditHoursAttempted (because in July only courses with final marks are included in the count).

The element will be re-sent with the attribute action=”delete” inside the XML start tag. The element will contain either:

• empty XML tags if the PESC element is optional
• a code symbolizing “Not Reported” if the PESC element is required

Note: For fields that are always sent together in groups (e.g., all of the applicant’s name components), the other related elements in the group will also be re-sent, but without an “action” attribute inside their XML start tags to denote that they have not changed.

The ApplicationDetail tag would have attribute action=”add” since this would be an added choice. The action=”update” will only be used for choices that you have previously received.

The unique key for a specific instance of a specific applicant using the XML tag names would be:

1. TransmissionData.DocumentID (i.e., the unique applicant)
2. TransmissionData.NoteMessage (i.e., the unique distribution #)
   
   If you wanted to be even more specific to the program choice level (e.g., a 105 applicant applies to 2 Toronto programs, but only 1 of those has a choice-level error) you could also add:
   
3. ApplicationDetail.NoteMessage (i.e., the OUAC application #)

Or, using the distro table field names:

1. UAC_DOC_ID
2. UAC_2620_DISTID
3. UAC_0030_APPL_NBR (for more specific program choice level only)

Yes.

Yes.

To help relate the XML version to the current flat file, you can filter column Q of the OUAC-PESC XML Mapping spreadsheet for the Functional Acknowledgement.

No, you can choose to do XML or flat file for University Decisions/Online Responses separately from your choice of XML or flat file for distributions.

The decision file process will change for the “O” divisions, whether you go XML or not. So if you stay with the flat text file, then you will be expected to send and receive OLSAS and ORPAS decision data in the newly defined format.

In the current system for UAS, we combined the “Previous Application Year” and “Previous Registered Year” into 1 element: 430.

If an applicant indicated they had previously applied and registered, then we would just send the registered data. This is currently being sent at the program choice level. Moving forward, we will report both and will use the existing Element 855. The mneumonic was changed because the leading “E” meant TEAS, and this is no longer a TEAS-only element.

Yes, this refers to Element 440, which has been discontinued.

Yes. We do not have any intention to send CEGEP or BC Transcript data as anything other than “whole packages”.

The problem is that OUACAcademicRecordBatch is a generic schema designed to carry any content, so it doesn’t have any reference to the application schema for your importer to follow.

There are 2 possible solutions:

1. Import the OUACAdmissionsApplication_v1.3.0., then manually add the necessary OUACAcademicRecordBatch tags before and after what gets imported (that’s only about 15 sets of tags). Your mapper should allow you to manually adjust the schema after it has been imported.
2. If 1. does not work, or if you don’t want to do it each time you have to re-import your schema, you could modify your copy of the OUACAcademicRecordBatch schema so it does contain the application and then import that version of OUACAcademicRecordBatch.

Here are all of the changes we think should work for you. (Note: We don’t have a way to test this, but did similar “tweaks” to allow the HighSchoolTranscript to be read into the useextensions schema.) Make sure to do all these steps:

1. In OUACCoreMain_v1.14.0.xsd:
   • inside line 7, just after the string xmlns:ouac=”urn:ca:ouac:message:useextensions:v1.0.0″ add the following string (leaving one blank space between): xmlns:AdmApp=”urn:org:pesc:sector:OUACAdmissionsApplication:v1.3.0″
   • after line 8 which imports namespace “useextensions.xsd”, add this line: <xs:import namespace=”urn:org:pesc:sector:OUACAdmissionsApplication:v1.3.0″ schemaLocation=”OUACAdmissionsApplication_v1.3.0.xsd”/>
   • search for the definition of complex type “AcademicRecordBatchType”. Change its child element definition from:
     <xs:any namespace=”##other” processContents=”strict” minOccurs=”0″ maxOccurs=”unbounded”/>
     to be this instead:
     <xs:element name=”AdmissionsApplication” type=”AdmApp:AdmissionsApplicationType” minOccurs=”0″ maxOccurs=”unbounded”/>
2. In OUACAdmissionsApplication_v1.3.0.xsd:
   • You will want to create a new complexType element called “AdmissionsApplicationType” by copying and modifying the existing element “AdmissionsApplication”. For an example, please see what we did for the high school transcript inside the file OUACHighSchoolTranscript_v1.5.0.xsd

Yes, they are correct.

They are not needed for PESC because either:

• they only apply to flat file (e.g., 2630 “number of records”) or
• they are handled some other way (e.g., by the new XML tags’ “action=” attribute)

Yes, if you are receiving the batched files (i.e., not the zipped set of files), then checking the Batch Envelope would be enough.

For more flexibility, should you decide to switch to the zip files later, you can also check the TransmissionData within each application. PSIS will always be populated at each of the locations and is a good one to use.

You would never need to check either the HSTranscript or EducationTestscores, unless you decide to “extract” those documents out of the application “package” for each applicant (i.e., the HSTranscript and EducationTestscores are designed to stand alone, so some universities may choose to “extract” them at certain times during the admission cycle, for example, to process 101 grades separately from other application-related amendments).

Yes, for each combination of admissions cycle and what the OUAC currently calls a “division” it will remain the same (e.g., if you happen to have the same person (EMPLID) applying to both Non-Secondary 2017 and TEAS 2017, they would have 2 distinct document IDs).

Also, to distinguish the original “create” version of the document from any subsequent “amendments” that are sent, use the document ID together with the distribution ID (UAC_2620_DISTID)