Information Standard for Party and Party Contact Specification using Government of Ontario CDE XML Schema (GOCDES)

Transcription

1 Information Standard for Party and Party Contact Specification using Government of Ontario CDE XML Schema (GOCDES) Government of Ontario IT Standards (GO-ITS) Document No Version Status: Approved OCCIO/OCCTO MANAGEMENT BOARD SECRETARIAT CORPORATE ARCHITECTURE AND STANDARDS BRANCH TECHNICAL STANDARDS SECTION Last Review Date: Feb 8 th, 2005 Queen's Printer for Ontario, 2005.

2 Foreword Government of Ontario Information & Technology Standards are the official publications on the standards, guidelines, technical reports and preferred practices adopted by the Information & Technology Standards Council under delegated authority of the Management Board of Cabinet. These publications support the Management Board Secretariat's responsibilities for coordinating standardization of Information and Technology in the Government of Ontario. Publications that set new or revised standards provide policy guidance and administrative information for their implementation. In particular, they describe where the application of a standard is mandatory and specify any qualifications governing its implementation. 2

3 Table Of Contents INTRODUCTION Introduction to GOCDES Applicability Requirement Levels Document Types and Filenames Purpose of the Standard Recommended Versioning and/or Change Management Contact Information Type of Standard Acknowledgements Development Team Reviewers Group and Committee Reviews...9 COMMON DATA ELEMENTS XML SCHEMAS CDES Logical Design Design Principles CDES Party and Party Contact Sub Areas CDES Party and Party Contact Data Models Party Common Party Contact Individual Organization GOCDES Physical Design XML Schema Namespaces XML Schemas GOPartyCommon GOPartyContact GOIndividual GOOrganization Usage Rules General GOCDES Usage Rules GOCDES Party and Party Contact Schema Usage Rules Errata Document Numbering Copyright APPENDIX A: ADDITIONAL INFORMATION Abbreviations and Acronyms Change Control Technical Standards Change Control Process Change Control Procedure Change Control Documentation GOCDES Change Record Known Issues List of Related Documents References

4 Table Of Figures Figure 1 CDES Subject Areas Overview Figure 2 Party Subject Area Overview Figure 3 Address Subject Area Overview Figure 4 Party Common Logical Data Model Figure 5 Party Contact Logical Data Model Figure 6 Individual Logical Data Model Figure 7 Organization Logical Data Model Figure 8 Party and Party Contact Namespaces Figure 9 Extension of Party Role Figure 10 Example of N-ary Relationships between Parties

5 Introduction 1 Introduction to GOCDES GOCDES is the name of the authoritative corporate (Government of Ontario) version of the Common Data Elements XML Schemas (CDES). It is developed, owned and maintained by the Corporate Architecture and Standards Branch (CASB) within the Office of Corporate Chief Technology Officer (OCCTO) in the Management Board Secretariat (MBS) of the Government of Ontario. GOCDES is developed based on Common Data Element Model (CDEM) Party Business View Logical Data Model (BVLDM) version [see Related Documents 1], which was approved by Corporate Architecture Review Board in May The very first release of GOCDES, the GOCDES version 1.7d [see Related Document 4], was based on version 1.7d of CDEM Business View Logical Data Model, Party and Address subject areas, and adopted as GO-ITS Another earlier release of GOCDES [see Related Document 5], the GOCDES Address version that was adopted as GO-ITS 27.1, covers only the Address subject area. The design of GOCDES version is leveraged on the previous XML schema design and development experience and, in particular, the feedback on the usage of previous release of GOCDES in the OPS Electronic Service Delivery for individuals (ESDi) project. The CDES design uses the model driven approach by starting from a Logical Data Model (CDES LDM), then transforming it into a CDES XML Schema Physical Data Model (CDES PDM) using the transformation rules outlined in Section 6.4 of the Information Modeling Handbook [see Reference 1], and finally to generate XML schema codes. The design of CDES LDM applies a set of design principles, with a clear focus on providing solutions to problems and issues emerged during the usage of previous CDES releases. This document is organized as follows: Section 2 presents the CDES Design Principles, CDES Party and Party Contact sub-areas (Individual, Organization, Party Common, Party Contact, and Address), and their LDMs. The modeling technique used is UML (Unified Modeling Language) diagram notation. Section 3 elaborates GOCDES Physical Design, which is composed of the definition of GOCDES namespaces, XML Schema tree diagrams, and fragments of the GOCDES XML Schema code. The XML Schema codes indicate the significant parts of the XML schemas and the data integrity rules. The rules are presented either as XML Schema facets or as specifications in the application information of XML Schema annotations. Section 4 introduces the CDES Usage Rules. These rules indicate mandatory and optional parts of the standard, as well as recommendations on how to use GOCDES in the OPS applications. Finally, the Appendix A section covers other additional information such as Change Control, and provides a complete list of all related documents and references. All listed documents are attached in this package and also available for download from the ITSC website. 5

6 1.1 Applicability This publication applies to the Ontario Public Service (OPS) ministries and clusters. It also applies to all agencies reclassified to regulatory/adjudicative, advisory and operational to which standards have been regulated. Kindly refer to for a list of provincial government agencies with their classification under the current classification system, as well as their previous Schedule under the former Schedule system. 1.2 Requirement Levels This publication contains mandatory requirements for all applications, projects, cluster or ministry common XML schemas within OPS that utilize the concepts of Common Data Elements, and use of GOCDES components. 1.3 Document Types and Filenames Acronym GO-ITS File name: Type Government of Ontario Information Technology Standard GO-ITS 27.2 IT Standard Version doc 1.4 Purpose of the Standard The Common Data Elements are standardized definitions of information that is generic to all mandates of the Government of Ontario. They provide information technology staff with a detailed, flexible template, or menu, of reusable names, definitions and formats for data elements. Using Common Data Elements can save time, provide new ideas, ensure consistency, enforce standards and integrate information. GOCDES is developed based on the concepts of Common Data Elements Model. The design of GOCDES is leveraged on previous XML schema design and development experience and, in particular, the feedbacks on the usage of previous released XML schema within the Ontario Public Service (OPS). GOCDES covers the Parties (individuals, organizations and their roles), the Party Contacts, and Addresses used to establish the Party Contacts. The Addresses cover various forms of addresses, such as mailing address, physical address, telephone address, address or net address. GOCDES could be used in the following cases: Sharing OPS document structure rules within OPS or across jurisdiction as a common format for data exchange. Automatic validation of OPS s own XML data or data from external s. Exchanging data between heterogeneous databases. XML parses to supply default values or fixed values for attributes that are not explicit in each XML document instance. 1.5 Recommended Versioning and/or Change Management Due to the dynamic and changing nature of the current work on the Common Data Elements Model, this standard will require further changes to certain areas. This work is evolving through major project usage feedback and Domain Working Group enhancements to the model. Future changes are being managed through the EAPM-based change control procedure - see appendix 6

7 for this procedure. As this work evolves and receives approval through the Domain working Group, there will be a new release of this schema brought forward to the Standards Committee as an update to this standard. If you have questions or comments about the GOCDES content or have the needs to make modification to the current release of GOCDES, please contact the Information Architect or the equivalent in your I&IT Cluster. The cluster architect will then consult with MBS Corporate Architecture Branch if it is required. Issues may be resolved by cluster or corporate architecture governance bodies. 1.6 Contact Information Contact 1 Contact 2 Name Technical Coordinator Organization/ Ministry Management Board Secretariat Division Office of the Corporate Chief Technology Officer Branch Corporate Architecture and Standards Branch Section/ Unit Technical Standards Section Office Phone (416) go-its@gov.on.ca 1.7 Type of Standard Check One X Type of Standard Implementation Standard requirements or specifications, which may include advise and guidance, for the implementation of a technology or the performance of an activity related to the use of technology, applicable throughout the provincial government. (e.g. mandatory O/S configuration requirements, security procedures, web page design requirements etc.). Information Standard specifications for a data format (e.g. XML schema, metadata, and/or related data models) Technical Standard - networking and communications specifications, protocols, interfaces (API s) (e.g. standards adopted from recognized standards development organizations such as W3C, OASIS or IETF such as TCP/IP, XML, SOAP, etc.) Architecture Standard application patterns, architecture and standards principles governing the design and technology decisions for the development of major enterprise applications Please indicate if this standard should be restricted to publishing on the Internal (Intranet) IT Standards web site or whether it is intended for publishing on the public (Internet) Government of Ontario IT Standards web site. Check One Publish as Internal or External Internal Standard External Standard 7

8 1.8 Acknowledgements Development Team Name Cluster/Ministry Branch Thomas Chen Management Board Secretariat Corporate Architecture and Standards Branch Adnan Kulenovic Management Board Secretariat Consultant to Corporate Architecture and Standards Branch Eric Wong Management Board Secretariat Corporate Architecture and Standards Branch Reviewers Name Cluster/Ministry Branch Ajay Muppidi Land Res Cluster, Ministry of Business Service and Solution Branch Environment Alana Boltwood Management Board Secretariat Corporate Architecture and Standards Branch Anna Nadin Justice Cluster Technology Strategy and Controllership Barb Stead Central Agencies Cluster, Ministry of Finance Enterprise Business Solutions Branch Brady Thompson Community Services Cluster Planning and Architecture Bill Powell Management Board Secretariat Corporate Architecture and Standards Branch Caroline Crnekovic Management Board Secretariat Strategy, Policy & Planning Branch Claudia Guajardo-Yeo Human Services Cluster Information Management and IT Security David Rapaport Community Services Cluster, Ministry of Education and Training Information Management, Technology and Services Dean Pigeon Management Board Secretariat Corporate Architecture and Standards Branch Frank Cheng Central Agencies Cluster, Ministry of Enterprise Technology Solutions Branch Finance Fred Woodhall Land Res Cluster, Ministry of Agriculture and Foods Information Technology and Services Garry Stoddart Transportation Cluster Information Res Management Gennaro Giampaolo Economics and Business Cluster Planning & Architecture George Berelidze Economics and Business Cluster Planning & Architecture George Silva Greg Bay Land Res Cluster, Ministry of Natural Res Land Res Cluster, Ministry of Natural Res Business Solution and Forest Land Information of Ontario Joanne Venema Human Services Cluster Information Management and IT Security Kamel Toubache Community Services Cluster Planning and Architecture Karin Wood Transportation Cluster Consultant to Road User Safety System Renewal Kim Gurnett Land Res Cluster, Ministry of Land and Res Data Administration Natural Res Lorie Oblak Transportation Cluster Strategic Planning and Architecture 8

9 Moira Watson-Turner Land Res Cluster Consultant to Land and Res Data Administration Murray Edmund Economics and Business Cluster Planning & Architecture Norman Lee Management Board Secretariat Corporate Architecture and Standards Branch Saumitra Hore Simon Loban Land Res Cluster, Ministry of Environment Community Services Cluster, Ministry of Education Information Management and Technology Branch Business Planning & Expenditure Management Branch Sylvia Smart Management Board Secretariat Corporate Architecture and Standards Branch Group and Committee Reviews Check Area Date: (month/year) Technical Standards Unit, Corporate Architecture Branch, OCCTO 02/2005 Corporate Architecture and Standards Branch (CASB Architects), OCCTO 01/2005 Infrastructure Development Branch & iserv, OCCSD Corporate Security Branch, OCCS Strategy, Policy, Planning and Management Branch (SPPM, OCCS) Corporate ACT and Domain Working Groups Information Architecture Domain (IADWG) 02/2005 Technology Architecture Domain (TADWG) Application Architecture Domain (AADWG) Security Architecture Working Group (SAWG) Cluster ACT/ARB (for cluster standards promoted to corporate standards) Clusters XML Schema Development Team 01/2005 IT Standards Council 03/2005 9

10 Common Data Elements XML Schemas 2 CDES Logical Design GOCDES and their associated Logical Data Models and Physical Data Models are owned by the Corporate Architecture and Standards Branch (CASB) in the Management Board Secretariat (MBS) of the Government of Ontario. They are semantically identical to the CDE Model. For more information, please contact the Manager, Information And Business Architecture at Design Principles This section lists the design principles that guided development of GOCDES Completeness: CDES LDM must implement all business requirements and rules that have been expressed in the CDEM BVLDM. In other words, CDES LDM must be semantically equivalent to its business data model, but not necessarily map its structures directly. 2. Consistency: CDES LDM must maintain the consistency in the use of entity names, attribute names and design patterns of data model. Similarly, GOCDES Schema must also maintain the consistency in the use of schema type names, element names, attribute names and structures of design patterns within the schema. 3. Stability: GOCDES should be designed in a way that will minimize the impact of the future changes of business requirements. 4. Reusability/Extendibility: GOCDES must be able to support the extension and re-composition of data components to meet specific requirements of OPS applications. 5. Compatibility: CDES LDM should align with ministry and cluster logical data models wherever is possible, especially when a ministry or cluster logical data model is shared and supported by several clusters or ministries. 6. Standardization: Data element names used in the CDES LDM, GOCDES PDM and schemas should follow OPS corporate naming standards and conventions as specified in OPS IMH. 7. Simplicity: CDES LDM and GOCDES PDM should avoid any unnecessary complexity and make GOCDES simple for implementation, maintenance and support. 8. Robustness and Modularity: GOCDES should be organized into a few smaller, loosely coupled, and well-defined modules (subject sub-areas), to enable independent change management, versioning and customization on each of these individual modules. 9. Performance: The design of GOCDES should aim at minimizing run-time processing costs. XML Schema and XML instances should be simple and short to minimize parsing, processing and/or application binding costs. 10. Compatibility with Validation Tools: The design of GOCDES should enable easy integration of GOCDES based applications with application data validation software. 11. Compatibility with Code Generating Tools: The usage rules of GOCDES should allow customization of XML Schemas to meet specific requirements of Java to XML binding tools (JAXB). 10

11 2.2 CDES Party and Party Contact Sub Areas CDES Party and Party Contact LDM is divided into the following sub areas, as shown in Figures 1, 2 and 3: Party Contact o Party Party Common Individual Organization o Address Address Common Canada Address US Address International Address Electronic Address Figure 1 CDES Subject Areas Overview 11

12 Figure 2 Party Subject Area Overview Figure 3 Address Subject Area Overview 2.3 CDES Party and Party Contact Data Models The CDES LDM is expressed in UML diagrams. It is in the output format of Rational Rose, a CASE 1 tool which uses Unified notation (see the "Components of a Data Model" section of the Information Modeling Handbook) Party Common Party Common Elements are data elements (classes, elements, attributes, and association) that are commonly shared in the Party subject area, as shown in Figure 4. 1 Computer-Aided Software Engineering (CASE) tools are software programs that facilitate data and process modeling. 12

13 <<complexty pe>> Party <<elt>> ProgramParty ID [0..1] <<elt>> Pref erredof f iciallanguagecode [0..1] : OntOf f iciallanguagety pe <<elt>> Pref erredlanguagecode [0..1] : ISO639-1LanguageTy pe <<att>> f irstnationsstatusflag [0..1] : FlagTy pe +Object +Party plays 1 0..* +Subject 0..* relates to 1 +Subject +Object 1 +Subjec trelations hip 0..* 0..* +ObjectRelationship <<complexty pe>> Party Relationship <<att>> ty pecode : Party RelationshipCodeTy pe <<elt>> StartDate [0..1] : Date <<elt>> EndDate [0..1] : Date <<complexty pe>> Party Role <<elt>> StartDate [0..1] : Date <<elt>> EndDate [0..1] : Date +ObjectRole +Party Role 1..* 1 1 +SubjectRole described by +Role 0..* 1 <<complexty pe>> Role <<elt>> Name : RoleNam ety pe <<elt>> Code [0..1] : RoleCodeType <<elt>> Desc [0..1] : DescriptionTextTy pe <<complexty pe>> Ownership Relationship <<elt>> Ownership Percent [0..1] : PercentageTy pe +ObjectRoleRelationship 0..* 0..* <<complexty pe>> Party Role Relationship +SubjectRoleRelationship <<att>> ty pecode : Party RelationshipCodeTy pe <<elt>> StartDate [0..1] : Date <<elt>> EndDate [0..1] : Date Rule 1: if exist (EndDate) then exist (StartDate) Rule 2: If exist (EndDate) then EndDate >= StartDate <<enum eration>> Party RelationshipCodeTy pe Member of = MemberOf Represented by = RepresentedBy Owned by = OwnedBy Suc ces sor of = Succ ess orof Part of = PartOf Linked to = LinkedTo <<enumeration>> FlagTy pe Yes = Yes No = No <<enumeration>> OntOf f iciallanguagety pe English = en French = f r Figure 4 Party Common Logical Data Model Party Contact Figure 5 shows Party Contact logical data model. 13

14 <<complextype>> Contact List <<elt>> Desc [0..1] : DescriptionTextType <<enumeration>> ContactPurposeType Billing = Billing General Contact = General Shipping and Delivering = Shipping <<enumeration>> ContactAddressUsageType Business = Business Personal = Personal Vacation = Vacation <<enumeration>> ContactTimeType Weekdays = Day Evenings = Evening Weekends and holidays = Weekend contains +PartyRole 0..* <<complextype>> Party Role <<elt>> StartDate [0..1] : Date <<elt>> EndDate [0..1] : Date <<complextype>> Party Role Address <<att>> usagetypecode [0..1] : ContactAddressUsageType <<att>> contactpurposecode [0..1] : ContactPurposeType <<att>> contacttimecode [0..1] : ContactTimeType <<elt>> StartDate [0..1] : Date <<elt>> EndDate [0..1] : Date <<elt>> EffectiveStartMonthDay [0..1] : MonthDayType <<elt>> EffectiveEndMonthDay [0..1] : MonthDayType <<elt>> PriorityNum [0..1] : SequenceNumType <<elt>> TempFlag [0..1] : FlagType <<elt>> InvalidFlag [0..1] : FlagType <<elt>> InvalidDate [0..1] : Date +PartyRoleAddress 0..* 0..* described by contact at 1 1..* +PartyRole 0..* 0..1 located at +Address 1..* <<complextype>> Address <<elt>> ValidStartDate [0..1] : Date <<elt>> ValidEndDate [0..1] : Date plays Rule 1: if exist (EndDate) then exist (StartDate) Rule 2: if exist (EndDate) then EndDate >= StartDate Rule 3: if exist (EffectiveStartMonthDay) then exist (EffectiveEndMonthDay) Rule 4: if not exist (EffectiveStartMOnthDay) then not exist (EffectiveEndMonthDay) Rule 5: if InvalidFlag = 'No' then not exist (InvalidDate) Rule 6: if InvalidFlag = 'Yes' then exist (InvalidDate) Rule 7: if exist (Address.ValidStartDate) & exist (StartDate) then StartDate >= Address.ValidStartDate Rule 8: if exist (Address.ValidEndDate) & exist (EndDate) then EndDate <= Address.ValidEndDate Rule 9: if exist (PartyRole.StartDate) & exist (StartDate) then StartDate >= PartyRole.StartDate Rule 10: if exist (PartyRole.EndDate) & exist (EndDate) then EndDate <= PartyRole.EndDate +Role 1 <<complextype>> Role <<elt>> Name : RoleNameType <<elt>> Code [0..1] : RoleCodeType <<elt>> Desc [0..1] : DescriptionTextType +Party 1 <<complextype>> Party <<elt>> ProgramPartyID [0..1] <<elt>> PreferredOfficialLanguageCode [0..1] : OntOfficialLanguageType <<elt>> PreferredLanguageCode [0..1] : ISO639-1LanguageType <<att>> firstnationsstatusflag [0..1] : FlagType +Subject 0..* 0..* +Object relates to <<enumeration>> FlagType Yes = Yes No = No <<enumeration>> OntOfficialLanguageType English = en French = fr Figure 5 Party Contact Logical Data Model Individual As shown in Figure 6, an Individual is a person who may be alive, unborn or deceased, or may be acting in a personal or professional capacity. Individual is composed of Language Skill and Individual Name Part 14

15 <<complextype>> Party <<elt>> ProgramPartyID [0..1] <<elt>> PreferredOfficialLanguageCode [0..1] : OntOfficialLanguageType <<elt>> PreferredLanguageCode [0..1] : ISO639-1LanguageType <<att>> firstnationsstatusflag [0..1] : FlagType +Object 0..* relates to +Subject 0..* <<enumeration>> FlagType Yes = Yes No = No <<enumeration>> GenderType Not Known = 0 Male = 1 Female = 2 Not Specified = 9 <<complextype>> Language Skill <<elt>> Name : ISO639-1LanguageType <<att>> code : ISO639-1LanguageCodeType <<att>> preferredofficialflag [0..1] : FlagType <<att>> preferredflag [0..1] : FlagType <<att>> firstlearnedflag [0..1] : FlagType <<att>> speakflag [0..1] : FlagType <<att>> readflag [0..1] : FlagType <<att>> writeflag [0..1] : FlagType <<complextype>> Individual <<elt>> HonorificTitle [0..1] : HonorificType <<elt>> GivenName [0..1] : NameTextType <<elt>> LastName [0..1] : NameTextType <<elt>> FormerLastName [0..1] : NameTextType <<elt>> BirthDate [0..1] : Date <<elt>> DeathDate [0..1] : Date <<elt>> GenderCode [0..1] : GenderType <<elt>> LegalMaritalStatusCode [0..1] : MaritalStatusType <<elt>> Height [0..1] : HeightType <<elt>> PositionTitle [0..1] : NameTextType <<elt>> SignatureImage [0..1] : Base64Binary <<elt>> PhotoImage [0..1] : Base64Binary <<elt>> SocialInsuranceNum [0..1] : SocialInsuranceNumType uses +LanguageSkill 0..* named by 0..* +IndividualName <<complextype>> Individual Name Part <<elt>> Name [0..1] : NameTextType <<elt>> StartDate [0..1] : Date <<elt>> EndDate [0..1] : Date <<elt>> InitialsText [0..1] : NameInitialsTextType <<att>> formalitycode : NameFormalityType <<att>> typecode : NameType <<att>> groupnum : SequenceNumType <<att>> sequencenum [0..1] : SequenceNumType <<att>> initialsusedflag [0..1] : FlagType <<att>> preferredflag [0..1] : FlagType <<enumeration>> OntOfficialLanguageType English = en French = fr <<enumeration>> MaritalStatusType Single = N Married = M Separated = S Divorced = D Widowed = W Rule 1: if exist (BirthDate) & exist (DeathDate) then DeathDate >= BirthDate <<enumeration>> NameFormalityType Legal Name = Legal Formal Name = Formal Informal Name = Informal <<enumeration>> NameType Preceding Title = 10 Honorific Title = 20 First Name = 30 Middle Name = 40 Last Name Prefix = 50 Last Name = 60 Alias = 70 Generation ID = 80 Name Suffix = 90 Rule 4: if InitialsUsedFlag = 'Yes' then exist (InitialsText) Rule 5: if not exist (InitialText) then not exist (InitialUsedFlag) Rule 6: if not exist (Name) then exist (InitialsText) Rule 7: if not exist (InitialsText) then exist (Name) Rule 2: if exist (EndDate) then exist (StartDate) Rule 3: If exist (EndDate) then EndDate >= StartDate Figure 6 Individual Logical Data Model Organization An Organization is a group of Individuals that has allocated res. An Organization must represent itself as a unit, with a leader or a single point of contact. There are 3 different types of Organizations: Formal Organization, Informal Organization, and Admin Organization Unit, as shown in Figure 7 15

16 <<complextype>> Party <<elt>> ProgramPartyID [0..1] <<elt>> PreferredOfficialLanguageCode [0..1] : OntOfficialLanguageType <<elt>> PreferredLanguageCode [0..1] : ISO639-1LanguageType <<att>> firstnationsstatusflag [0..1] : FlagType 0..* +Object +Subject 0..* relates to <<enumeration>> OrgNameFormalityType Legal = Legal Operating, Trade, Style, or Business Name = Operation Statute or Regulation = Statute Common = Common Abbreviation or Acronym = Abbreviation <<enumeration>> OrganizationStructureType Sole Proprietorship = 01 Partnership = 02 Corporation = 03 Unknown = 98 Other = 99 <<complextype>> Organization <<elt>> Name [0..1] : OrgNameTextType <<elt>> ActivityDesc [0..1] : DescriptionTextType <<elt>> StartDate [0..1] : Date <<elt>> EndDate [0..1] : Date <<complextype>> Organization Name named by 0..* <<att>> formalitycode : OrgNameFormalityType <<att>> Of ficiallanguagecode : OntOfficialLanguageType +OrganizationName <<elt>> Name : OrgNameTextType <<elt>> StartDate [0..1] : Date <<elt>> EndDate [0..1] : Date Rule 3: if exist (Incorporation Jurisdiction Choice) then OrganizationTypeCode = '03' <<enumeration>> FlagType Yes = Yes No = No Rule 1: if exist (EndDate) then exist (StartDate) Rule 2: If exist (EndDate) then EndDate >= StartDate <<enumeration>> OntOfficialLanguageType English = en French = fr <<complextype>> <<complextype>> <<complextype>> <<complextype>> Incorporation Country Formal Organization Informal Organization Admin Organization Unit <<elt>> CountryCode : ISO3166-1CountryCodeType <<elt>> FiscalYearEndMonthDay [0..1] : MonthDayType <<elt>> ActivityClassificationCode [0..1] : ActivityClassificationType <<elt>> OrganizationTypeCode [0..1] : OrganizationStructureType jurisdictiontypecode = 'Federal' determined by <<enumeration>> <<choice>> JurisdictionType identified by registered as Incorporation Jurisdiction Choice Federal level jurisdiction = Federal <<att>> jurisdictiontypecode : JurisdictionType Provincial, State, or Territorial level Jurisdiction = Province +FederalBusinessID 0..* 0..* +OntBusinessRegistration jurisdictiontypecode in ('Province', 'State' 'Territory') <<complextype>> Federal Business Identification <<elt>> RegistrationNum : RegistrationNumType <<elt>> ProgramID : ProgramIdentifierType <<elt>> ReferenceNum : ReferenceNumType <<complextype>> Ontario Business Registration <<elt>> BusinessRegistrationNum : BusinessRegistrationNumType <<elt>> EstablishmentTypeCode [0..1] : BusinessEstablishmentType <<elt>> StatusCode [0..1] : BusinessStatusType <<complextype>> Incorporation Province State <<elt>> ProvinceStateCode : CanadaPostProvinceStateCodeType Figure 7 Organization Logical Data Model 16

17 3 GOCDES Physical Design 3.1 XML Schema Namespaces GOCDES Physical Data Model (PDM) has two parts: a) XML Schema namespaces, and b) tree diagrams with associated XML code that describes the data integrity rules. The following namespaces are defined in GOCDES 2.0.0: GOShared GOPartyCommon GOPartyContact GOOrganization GOIndividual Figure 8 Party and Party Contact Namespaces Figure 8 presents the namespaces and associated logical entities in a diagrammatic form. A namespace corresponds to a logical sub area identified in the CDES LDM, with exception of GOShared. The GOShared namespace contains generic common elements, such as Date, Time, Flags, etc., which are shared among all CDE subject areas. PDMs and XML Schemas for each of these namespaces are described in the subsequent sections. 3.2 XML Schemas GOPartyCommon 17

18 Schema GOCommonParty2.0.0.xsd TargetNamespace: Imported Namespace: GOCommonParty2.0.0 GOShared2.0.0 GOCommonAddress2.0.0 Complex types OwnershipRelationshipType PartyRelationshipType PartyRoleAddressType PartyRoleRelationshipType PartyRoleType PartyType RoleNameType RoleType Simple types ContactAddressUsageType ContactPurposeType ContactTimeType PartyIDType PartyRelationshipCodeType RoleCodeType Schema GOCommonParty2.0.0.xsd complextype OwnershipRelationshipType diagram <complextype name="ownershiprelationshiptype"> <documentation xml:lang="en">define Ownership Relationship as a special type of Party Relationship by extending the Party Relationship.</documentation> <complexcontent> <extension base="pc:partyrelationshiptype"> <sequence> <element name="ownershippercent" type="shr:percentagetype" minoccurs="0"> 18

19 <documentation xml:lang="en">the percentage of ownership of one organization. </documentation> </sequence> </extension> </complexcontent> </complextype> complextype PartyRelationshipType diagram <complextype name="partyrelationshiptype"> <documentation xml:lang="en">definition of an associated relationship between two Parties</documentation> <sequence> <element ref="pc:subject" minoccurs="0"> <documentation xml:lang="en">information about the Subject (or Primary) Party in a party to party association relationship.</documentation> <element ref="pc:object" minoccurs="0"> <documentation xml:lang="en">information about the Object (or Secondary) Party in a party to party association relationship.</documentation> <sequence minoccurs="0"> <element ref="pc:startdate"> <documentation xml:lang="en">the date when a Party to Party association relationship starts.</documentation> <appinfo>data Integrity Rule: 1. IF EndDate of PartyRelationType is used THEN StartDate of PartyRelationType must also be used.</appinfo> <element ref="pc:enddate" minoccurs="0"> <documentation xml:lang="en">the date when a Party to Party relationship ends.</documentation> <appinfo>data Integrity Rule: 1. IF EndDate of PartyRelationType has a value THEN EndDate of PartyRelationType must be >= StartDate of PartyRelationshipType.</appinfo> 19

20 </sequence> </sequence> <attribute ref="pc:type" use="required"> <documentation xml:lang="en">a type that describes relationship between two Parties, Subject (or Primary) Party and Object (or Secondary) Party, such as structural relationships</documentation> </attribute> </complextype> 20

21 complextype PartyRoleAddressType 21

22 diagram 22

23 <complextype name="partyroleaddresstype"> <documentation xml:lang="en">an association of a Party Role to an Address for a time period and purpose.</documentation> <sequence> <sequence minoccurs="0"> <element ref="pc:startdate"> <documentation xml:lang="en">the date when the identified Party (Role) can be, or will be contacted at the specified Address.</documentation> <appinfo>data Integrity Rules: 1. IF EndDate of Contact is used THEN EndDate of Contact must >= StartDate of Contact. 2. IF StartDate of Contact AND ValidStartDate of ac:address are used THEN StartDate of Contact must >= ValidStartDate of ac:address. 3. IF StartDate of Contact and StartDate of PartyRole are used THEN StartDate of Contact must >= StartDate of PartyRole.</appinfo> <element ref="pc:enddate" minoccurs="0"> <documentation xml:lang="en">the date when the identified Party Role no longer can be contacted at the specified Address.</documentation> <appinfo>data Integrity Rules: 1. IF EndDate of Contact is used THEN EndDate of Contact must >= StartDate of Contact. 2. IF EndtDate of Contact AND ValidEndDate of ac:address are used THEN ValidEndDate of ac:address must >= EndDate of Contact. 3. IF EndDate of Contact and EndDate of PartyRole are used THEN EndDate of PartyRole must >= EndDate of Contact.</appinfo> </sequence> <sequence minoccurs="0"> <element name="effectivestartmonthday" type="shr:monthday" minoccurs="0"> <documentation xml:lang="en">a month and day combination that indicates on a yearly basis the beginning of the period (format mmdd) when the identified Party (Role) can be contacted at the specified Address. To be used for students, snowbirds, etc. who use addresses on a seasonal basis.</documentation> <element name="effectiveendmonthday" type="shr:monthday" minoccurs="0"> <documentation xml:lang="en">a month and day combination that indicates on a yearly basis the end of the period (format mmdd) when the identified Party Role can be contacted at the specified Address. To be used for students, snowbirds, etc. who use addresses on a seasonal basis.</documentation> <appinfo>data Integrity Rules: 1. IF EffStartMonthDay has a value THEN EffEndMonthDay must also have a value. 2. IF EffStartMonthDay is NOT used THEN EffEndMonthDay must NOT be used.</appinfo> </sequence> <sequence minoccurs="0"> <element name="invalid" type="shr:flagtype" default="no" minoccurs="0"> <documentation xml:lang="en">a flag that indicates whether the Party Role is no longer reachable at the Address, for example if mail has been returned, the telephone number is wrong or out of service, bounces, etc. The Address may or may not still be valid for other Party Roles of this or another Party. The default value is N (no), indicating that the address is thought to be valid.</documentation> <appinfo>data Integrity Rule:1. IF InvalidDate has a valid value THEN InvalidFlag must be = 'Yes'.</appinfo> <element name="invaliddate" type="shr:date" minoccurs="0"> <documentation xml:lang="en">the date when it was determined that the Party Role is no longer reachable at the Address, for example if mail has been returned, the telephone number is wrong or out of service, bounces, etc. The Address may or may not still be valid for other Party Roles. The default value for the InvalidDate is a default date determined by the application.</documentation> <appinfo>data Integrity Rule:1. IF InvalidDate is used AND StartDate of PartyAddress is used THEN InvalidDate must >= StartDate of PartyAddress. 2. IF InvalidDate is used AND EndDate of PartyAddress is used THEN EndDate of PartyAddress must >= InvalidDate.</appinfo> </sequence> <element ref="ac:address" minoccurs="0" maxoccurs="unbounded"> 23

24 <documentation xml:lang="en">a mandatory association between Contact to Address.</documentation> </sequence> <attribute name="usagetype" type="pc:contactaddressusagetype" use="optional"> <documentation xml:lang="en">a code that indicates whether this Contact Address is for Business, Personal, or Vacation use.</documentation> <appinfo>the recommended Contact Address Usage codes are: Business - Business Contact, Person â Personal Contact, Vacation - Vacation Contact. These codes are available in the CDER table CONTACT_ADDRESS_USAGE_TYPE.</appinfo> </attribute> <attribute name="contactpurpose" type="pc:contactpurposetype" use="optional"> <documentation xml:lang="en">a code that identifies the purpose of contacting a Party (Role) at a given Address.</documentation> <appinfo>the recommended Contact Purpose codes are: Billing - Billing Purpose, General - General Contact Purpose, Shipping - Shipping Purpose. These codes are also available in the CDER table CONTACT_PURPOSE_TYPE.</appinfo> </attribute> <attribute name="contacttime" type="pc:contacttimetype" use="optional"> <documentation xml:lang="en">a code that indicates when the Address is useful for contacting the Party Role: daytime, evenings or weekends, in the time zone of the Party Role being contacted.</documentation> <appinfo>the recommended Contact Time codes are: Day - Weekdays, Evening - Evenings, Weekend - Weekends and holidays. These codes are also available in the CDER table CONTACT_TIME_TYPE.</appinfo> </attribute> <attribute name="prioritynum" type="shr:sequencenumtype" use="optional" default="1"> <documentation xml:lang="en">a number that indicates a priority sequence of Addresses for contacting a Party (Role).</documentation> </attribute> <attribute name="temp" type="shr:flagtype" use="optional" default="no"> <documentation xml:lang="en">a flag that indicates whether or not an association of a Party via a Party Role to an Address is on a temporary base.</documentation> <appinfo>the default value for the flag is N (no), indicating that the Contact Address is not on a temporary base.</appinfo> </attribute> </complextype> 24

25 complextype PartyRoleRelationshipType diagram <complextype name="partyrolerelationshiptype"> <documentation xml:lang="en">definition of an associated relationship between two Parties or two Party Roles.</documentation> <sequence> <element name="subjectrole" type="pc:partyroletype" minoccurs="0"> <documentation xml:lang="en">information about the Subject (or Primary) Role in a party role to party role association relationship.</documentation> <element name="objectrole" type="pc:partyroletype" minoccurs="0"> <documentation xml:lang="en">information about the Object (or Secondary) Role in a party role to party role association relationship.</documentation> <sequence minoccurs="0"> <element ref="pc:startdate"> <documentation xml:lang="en">the date when a Party Role to Party Role association relationship starts.</documentation> <appinfo>data Integrity Rule: 1. IF EndDate of PartyRoleRelationType is used THEN StartDate of PartyRoleRelationType must also be used.</appinfo> <element ref="pc:enddate" minoccurs="0"> <documentation xml:lang="en">the date when a Party Role to Party Role relationship ends.</documentation> <appinfo>data Integrity Rule: 1. IF EndDate of PartyRoleRelationType has a value THEN EndDate of PartyRoleRelationType must be >= StartDate of PartyRoleRelationType.</appinfo> </sequence> </sequence> <attribute ref="pc:type" use="required"> <documentation xml:lang="en">a name that describes relationship between two Party Roles, the Subject (or Primary) Role and the Object (or Secondary) Role, such as structural relationships of responsibility, representation or collaboration.</documentation> 25

26 </attribute> </complextype> complextype PartyRoleType diagram <complextype name="partyroletype"> <documentation xml:lang="en">an association between a Party and a Role to signify that this Party plays this specific role.</documentation> <sequence> <element ref="pc:role"> <documentation xml:lang="en">the Role stores information about the nature of the role, independently of which Party plays the role. For instance, the name of the subtype of Party is stored in the RoleName. If necessary, an application could 26

27 maintain personal identifiers at the Party Role level rather than on Party level, so as not to combine information about a Party's multiple roles.</documentation> <element ref="pc:party" minoccurs="0"> <documentation xml:lang="en">the information about the Party that plays the specific role.</documentation> <element ref="pc:partyroleaddress" minoccurs="0" maxoccurs="unbounded"> <documentation xml:lang="en">this party role may have zero, one or many Addresses</documentation> <element name="subjectrolerelationship" type="pc:partyrolerelationshiptype" minoccurs="0" maxoccurs="unbounded"> <documentation xml:lang="en">information about the Subject (or Primary) Role in a party role to party role association relationship.</documentation> <element name="objectrolerelationship" type="pc:partyrolerelationshiptype" minoccurs="0" maxoccurs="unbounded"> <documentation xml:lang="en">information about the Object (or Secondary Role in a party role to party role association relationship.</documentation> <sequence minoccurs="0"> <element ref="pc:startdate"> <documentation xml:lang="en">the date when a Party starts to play a Role.</documentation> <appinfo>data Integrity Rule: 1. IF EndDate of PartyRoleType is used THEN StartDate of PartyRoleType must also be used.</appinfo> <element ref="pc:enddate" minoccurs="0"> <documentation xml:lang="en">the date when a Party ceases to play a Role.</documentation> <appinfo>data Integrity Rule: 1. IF EndDate of PartyRoleType has a value THEN EneDate of PartyRoleType must be >= StartDate of PartyRoleType.</appinfo> </sequence> </sequence> </complextype> 27

28 complextype PartyType 28

29 diagram 29

30 <complextype name="partytype"> <documentation xml:lang="en">an Individual or Organization, as identified and described by a program or service.</documentation> <sequence> <element ref="pc:programpartyid" minoccurs="0"> <documentation xml:lang="en">any identifier of a Party that is appropriate to the program or service. Identifiers may instead be assigned to subtypes of Party.</documentation> <element name="preferredofficiallanguagecode" type="shr:ontofficiallanguagetype" minoccurs="0"> <documentation xml:lang="en">a code that indicates which official language of Ontario the Party prefers to communicate in. Assumes the Party can read and/or write the language, as required for interacting with the Program or Service.</documentation> <element name="preferredlanguagecode" type="shr:iso639-1languagecodetype" minoccurs="0"> <documentation xml:lang="en">a code that indicates which language the Party prefers to communicate in. Assumes the Party can read and/or write the language, as required for interacting with the Program or Service. Programs and Services specify the set of languages in which they can interact with Clients or other Parties.</documentation> <element ref="pc:partyrole" minoccurs="0" maxoccurs="unbounded"> <documentation xml:lang="en">this party may play one or many party roles.</documentation> <element ref="pc:subject" minoccurs="0" maxoccurs="unbounded"> <documentation xml:lang="en">this party may be a Subject in a recursive Party to Party relationship.</documentation> <element ref="pc:object" minoccurs="0" maxoccurs="unbounded"> <documentation xml:lang="en">this party may be an Object in a recursive Party to Party relationship.</documentation> <element name="subjectrelationship" type="pc:partyrelationshiptype" minoccurs="0" maxoccurs="unbounded"> <documentation xml:lang="en">information about the Subject (or Primary) Relationship in a party to party association relationship.</documentation> <element name="objectrelationship" type="pc:partyrelationshiptype" minoccurs="0" maxoccurs="unbounded"> <documentation xml:lang="en">information about the Object (or Secondary) Relationship in a party to party association relationship.</documentation> </sequence> <attribute name="firstnationsstatus" type="shr:flagtype" use="optional" default="no"> <documentation xml:lang="en">a code that indicates whether the Party has First Nations, Native, Aboriginal or Indian status for purposes of the program or service. This may indicate status as a Registered Indian, a band or the council of a band, under the federal Indian Act.</documentation> </attribute> </complextype> 30

31 complextype RoleNameType diagram <complextype name="rolenametype"> <documentation xml:lang="en">domain definition for a name or identifier that identifies the role an organization or an individual plays.</documentation> <simplecontent> <restriction base="shr:bilingualtexttype"> <maxlength value="30"/> </restriction> </simplecontent> </complextype> complextype RoleType diagram <complextype name="roletype"> <documentation xml:lang="en">the RoleType stores information about the nature of the role, independently of which Party plays the role. For instance, the name of the subtype of PartyRole is stored in the RoleName. If necessary, an application could maintain personal identifiers at the Party Role level rather than on Party records, so as not to combine information about a Party's multiple roles.</documentation> <sequence> <element name="name" type="pc:rolenametype"> <documentation xml:lang="en">a name for the role identified by the associated RoleCode an organization or an individual plays.</documentation> <element name="code" type="pc:rolecodetype" minoccurs="0"> <documentation xml:lang="en">a code that indentifies a role an organization or an individual plays.</documentation> <element name="desc" type="shr:descriptiontexttype" minoccurs="0"> 31

32 <documentation xml:lang="en">a text that describes the role identified by the RoleCode an organization or an individual plays.</documentation> </sequence> </complextype> simpletype ContactAddressUsageType <simpletype name="contactaddressusagetype"> <documentation xml:lang="en">domain definition for a code that indicates whether this Contact Address is for Business, Personal, or Vacation use.</documentation> <appinfo>the recommended Contact Address Usage codes are: Business - Business Contact, Person - Personal Contact, Vacation - Vacation Contact. These codes are available in the CDER table CONTACT_ADDRESS_USAGE_TYPE.</appinfo> <restriction base="string"> <enumeration value="business"/> <enumeration value="person"/> <enumeration value="vacation"/> </restriction> </simpletype> simpletype ContactPurposeType <simpletype name="contactpurposetype"> <documentation xml:lang="en">domain definition for a code that identifies the purpose of contacting a particular Party (Role) at a specific Address.</documentation> <appinfo>the recommended Contact Purpose codes are: Billing - Billing Purpose, General - General Contact Purpose, Shipping - Shipping Purpose. These codes are also available in the CDER table CONTACT_PURPOSE_TYPE.</appinfo> <restriction base="string"> <enumeration value="billing"/> <enumeration value="general"/> <enumeration value="shipping"/> </restriction> </simpletype> simpletype ContactTimeType <simpletype name="contacttimetype"> <documentation xml:lang="en">domain definition for a code that indicates when an Address is useful for contacting the Party (Role): daytime, evenings or weekends, in the time zone of the Party being contacted.</documentation> <appinfo>the recommended Contact Time codes are: Day - Weekdays, Evening - Evenings, Weekend - Weekends and holidays. These codes are also available in the CDER table CONTACT_TIME_TYPE.</appinfo> <restriction base="string"> <enumeration value="day"/> <enumeration value="evening"/> <enumeration value="weekend"/> </restriction> </simpletype> simpletype PartyIDType <simpletype name="partyidtype"> <documentation xml:lang="en">the ProgramPartyID is defined as a place holder here and it should be replaced with a concrete element in the program and service specific schemas. </documentation> 32

33 <restriction base="shr:idtype"/> </simpletype> simpletype PartyRelationshipCodeType <simpletype name="partyrelationshipcodetype"> <documentation xml:lang="en">domain definition for a code that identifies an association relationship between two Parties or two Party Roles.</documentation> <appinfo>some recommended relationship type codes are: Member of, Represented by, Owned by (Ownership Percent may be used), Successor of (previous corporation), Part of (in an organization chart hierarchy), and Linked to (another Party record for the same real-world person or group). These values can be found in the CDER table Party_Relation_TYPE.</appinfo> <restriction base="string"/> </simpletype> simpletype RoleCodeType <simpletype name="rolecodetype"> <documentation xml:lang="en">domain definition for a code that indentifies a role an organization or an individual plays.</documentation> <restriction base="string"> <maxlength value="2"/> </restriction> </simpletype> GOPartyContact Schema GOContact2.0.0.xsd TargetNamespace: Imported Namespace: Complex types ContactType GOContact2.0.0 GOShared2.0.0 GOCommonAddress2.0.0 GOElectronicAddress2.0.0 GOCanadaAddress2.0.0 GOUSAddress2.0.0 GOInternationalAddress2.0.0 GOCommonParty2.0.0 GOOrganization2.0.0 GOIndividual2.0.0 Simple types complextype ContactType diagram <complextype name="contacttype"> 33

34 <documentation xml:lang="en">an association of a purpose and one or many Party Role Addresses</documentation> <sequence> <element name="desc" type="shr:descriptiontexttype" minoccurs="0"/> <element ref="pc:partyrole" maxoccurs="unbounded"/> </sequence> </complextype> GOIndividual Schema GOIndividual2.0.0.xsd TargetNamespace: Imported Namespace: GOIndividual2.0.0 GOShared2.0.0 GOCommonParty2.0.0 Complex types HeightType HonorificType IndividualNamePartType IndividualType LanguageSkillType NameInitialsTextType NameInitialUsageType NameTextType Simple types GenderType IndividualIDType MaritalStatusType MilitaryServiceNumType NameFormalityType NameType SocialInsuranceNumType complextype HeightType diagram <complextype name="heighttype"> <documentation xml:lang="en">domain definition used to describe the height of an individual, expressed in centimetres.</documentation> <simplecontent> <restriction base="shr:lengthtype"> <mininclusive value="0.00"/> </restriction> </simplecontent> </complextype> complextype HonorificType diagram <complextype name="honorifictype"> <documentation xml:lang="en">domain definition for various honorific titles used for an individual.</documentation> <appinfo>valid honorific type codes can be found in the CDER table HONORIFIC_TYPE. Use appropriate value of PreferredOfficialLanguageCode element in the PartyType for table value look-up or data validation.</appinfo> 34

35 <simplecontent> <restriction base="shr:bilingualtexttype"/> </simplecontent> </complextype> complextype IndividualNamePartType diagram <complextype name="individualnameparttype"> <documentation xml:lang="en">a part of an Individual's name or an associated honorific title, expressed in full or as an initial. Examples: John, Marion, Smith-Jones, M., O'C., van der, Right Reverend, Miss, Sgt., Dr., Jr., M.P.P., Ph.D.</documentation> <appinfo>individual Name Parts may contain apostrophes and hyphens. Spaces are not recommended as each word as a Name or Initial Text is stored separately. Use Sequence Code and Preferred Flag to indicate presentation preferences. All cultural variations (matronymics, family names in the middle name position, etc.) should be handled using Name Type Code and Preferred Flag to ensure correct presentation and sort order for the administrative purposes of a program or service.</appinfo> <sequence> <element name="name" type="i:nametexttype" minoccurs="0"> <documentation xml:lang="en">the full text of a name part, initials or title. Examples: John, J., Marion, Smith-Jones, van der, Right Reverend, Miss. </documentation> <appinfo>either Name or InitialsText is mandatory, and both can be specified. Data Integrity Rule: 1. IF InitialsText is NOT used THEN Name must be used.</appinfo> <element name="initialstext" type="i:nameinitialstexttype" minoccurs="0"> <documentation xml:lang="en">the abbreviated text of the name or title. Examples: M., O'C., Sgt., Dr., Jr., M.P.P., Ph.D.</documentation> <appinfo>either Name or InitialsText is mandatory, and both can be specified. Data Integrity Rule: 1. IF Name is NOT used THEN InitialsText must be used. 2. IF InitialsUsedFlag = 'Yes' THEN InitialsText must be used.</appinfo> <sequence minoccurs="0"> <element ref="pc:startdate"> <documentation xml:lang="en">the date when the Individual became known by this name. For legal names, this may be the Individual's Birth Date, marriage date, or the date when a name change was approved.</documentation> <appinfo>data Integrity Rule: 1. IF EndDate of IndividualNamePartType is used THEN StartDate of IndividualNamePartType must also be used.</appinfo> 35

36 <element ref="pc:enddate" minoccurs="0"> <documentation xml:lang="en">the date when the Individual ceased to be known by this name, if applicable. For legal names, this may be the Individual's marriage date or the date when a name change was approved.</documentation> <appinfo>data Integrity Rule: 1. IF EndDate of IndividualNamePartType has a value THEN EndDate of IndividualNamePartType must be >= StartDate of IndividualNamePartType.</appinfo> </sequence> </sequence> <attribute name="formality" type="i:nameformalitytype" use="required"> <documentation xml:lang="en">a code used to indicate the appropriate usage of the name.</documentation> </attribute> <attribute name="typecode" type="i:nametype" use="required"> <documentation xml:lang="en">a code used to indicate the type or position of an Individual Name Part, such as Title, First Name, Generation Identifier.</documentation> </attribute> <attribute name="groupnum" type="shr:sequencenumtype" use="required"> <documentation xml:lang="en">a unique identifier for the full name group that this Name Part belongs to. Used only if the program or service records more than one full name group of the same Formality Code (for example, multiple aliases of criminal suspects).</documentation> </attribute> <attribute name="sequencenum" type="shr:sequencenumtype" use="optional"> <documentation xml:lang="en">a number that indicates the presentation order of the Individual Name Part, within the Formality Code, Name Group Number, Name Type Code and Start Date. For example, the surname "Pashto Ubbink" would be broken into two parts, with Sequence Number = 1 for "Pashto" and Sequence Number = 2 for "Ubbink".</documentation> </attribute> <attribute name="preferred" type="shr:flagtype" use="optional"> <documentation xml:lang="en">a Flag to indicate if this Name Part is preferred for use.</documentation> </attribute> </complextype> 36

37 complextype IndividualType 37

38 diagram 38

39 <complextype name="individualtype"> <documentation xml:lang="en">an individual person who may be alive, unborn or deceased, and may be acting in a personal or professional capacity.</documentation> <complexcontent> <extension base="pc:partytype"> <sequence> <element name="honorifictitle" type="i:honorifictype" minoccurs="0"> <documentation xml:lang="en">the prefix used to formally address an Individual. e.g. Mr., The Honourable Dr., Sgt., etc. Use this as a simplified version of the set of Individual Name Parts with Name Type Code = Preceding Title or Title.</documentation> <appinfo>valid honorific type codes can be found in the CDER table HONORIFIC_TYPE. Use appropriate value of PreferredOfficialLanguageCode element in the PartyType for table value look-up or data validation.</appinfo> <element name="givenname" type="i:nametexttype" minoccurs="0"> <documentation xml:lang="en">the forename of an individual. It may be First Name, Middle Name, or initials or any combination thereof, and is used as legal, formal, informal or alias names, as required for the program or service.</documentation> <element name="lastname" type="i:nametexttype" minoccurs="0"> <documentation xml:lang="en">the surname of an individual. It may include Last Name Prefix, Last Name, Generation Identifier or Suffix, and is used as legal, formal, or informal names, as required for the program or service.</documentation> <element name="formerlastname" type="i:nametexttype" minoccurs="0"> <documentation xml:lang="en">the surname previously used by an individual. Most frequently required for a woman's maiden name (her last name at birth, or her adoptive name if adopted). It may include Last Name Prefix, Last Name, Generation Identifier or Suffix, and is used as legal, formal, or informal names, as required for the program or service.</documentation> <element name="individualname" type="i:individualnameparttype" minoccurs="0" maxoccurs="unbounded"> <documentation xml:lang="en">a part of an Individual's name or an associated honorific title, expressed in full or as an initial. </documentation> <element name="birthdate" type="shr:date" minoccurs="0"> <documentation xml:lang="en">the date of birth of an Individual. </documentation> <element name="deathdate" type="shr:date" minoccurs="0"> <documentation xml:lang="en">the date of death of an Individual.</documentation> <appinfo>data Integrity Rule: 1. IF both BirthDate and DeathDate are specified THEN DeathDate must be >= BirthDate.</appinfo> <element name="gendercode" type="i:gendertype" minoccurs="0"> <documentation xml:lang="en">the gender code of an Individual based on ISO 5218 codes for human sexes.</documentation> <element name="legalmaritalstatuscode" type="i:maritalstatustype" minoccurs="0"> <documentation xml:lang="en">a code used to describe the legal marital status of an Individual.</documentation> <element name="height" type="i:heighttype" minoccurs="0"> 39

40 <documentation xml:lang="en">a integer used to describe the height of an individual, expressed in centimetres.</documentation> <element name="positiontitle" type="i:nametexttype" minoccurs="0"> <documentation xml:lang="en">the name of the job or position occupied by the Individual within an Organization.</documentation> <element name="signatureimage" type="base64binary" minoccurs="0"> <documentation xml:lang="en">a graphic depiction of the Individual's handwritten signature on documents.</documentation> <element name="photoimage" type="base64binary" minoccurs="0"> <documentation xml:lang="en">a photographic representation of an Individual for the identification or adminstrative purposes of the program or service.</documentation> <element name="socialinsurancenum" type="i:socialinsurancenumtype" minoccurs="0"> <documentation xml:lang="en">the Social Insurance Number assigned to an Individual by the Government of Canada.</documentation> <element name="languageskill" type="i:languageskilltype" minoccurs="0" maxoccurs="unbounded"> <documentation>a list of language skills an Individual has.</documentation> </sequence> </extension> </complexcontent> </complextype> complextype LanguageSkillType diagram <complextype name="languageskilltype"> <documentation xml:lang="en">description of Language Skills possessed by an Individual. It covers the individual's native language (mother tongue), preferred language for communicating with the program or service, his/her ability to speak, read or write a language well enough to communicate with staff of a program or service.</documentation> <sequence> <element name="name" type="shr:iso639-1languagetype"> <documentation xml:lang="en">a code used to describe a major languages used in the world.</documentation> 40

41 </sequence> <attribute name="code" type="shr:iso639-1languagecodetype" use="required"> <documentation xml:lang="en">a code used to describe a major languages used in the world.</documentation> </attribute> <attribute name="peferredofficial" type="shr:flagtype" use="optional"> <documentation xml:lang="en">a flag to indicate whether the Language identified by the LanguageCode is a preferred official language (English or French) for communicating with the program or service.</documentation> </attribute> <attribute name="peferred" type="shr:flagtype" use="optional"> <documentation xml:lang="en">a flag to indicate whether the Language identified by the LanguageCode is a preferred for communicating with the program or service.</documentation> </attribute> <attribute name="firstlearned" type="shr:flagtype" use="optional"> <documentation xml:lang="en">a flag to indicate whether the Language identified by the LanguageCode is the native language (mother tongue) of the individual.</documentation> </attribute> <attribute name="speak" type="shr:flagtype" use="optional"> <documentation xml:lang="en">a flag to indicate whether the individual can speak the Language identified by the LanguageCode.</documentation> </attribute> <attribute name="read" type="shr:flagtype" use="optional"> <documentation xml:lang="en">a flag to indicate whether the individual can read in the Language identified by the LanguageCode.</documentation> </attribute> <attribute name="write" type="shr:flagtype" use="optional"> <documentation xml:lang="en">a flag to indicate whether the individual can write in the Language identified by the LanguageCode.</documentation> </attribute> </complextype> complextype NameInitialsTextType diagram <complextype name="nameinitialstexttype"> <documentation xml:lang="en">domain definition for individual name initials text.</documentation> <simplecontent> <restriction base="i:nameinitialusagetype"> <maxlength value="5"/> </restriction> </simplecontent> </complextype> 41

42 complextype NameInitialUsageType diagram <complextype name="nameinitialusagetype"> <documentation xml:lang="en">domain definition for individual name initials usage.</documentation> <simplecontent> <extension base="string"> <attribute name="initialused" type="shr:flagtype" use="optional" default="yes"> <documentation xml:lang="en">a Flag to indicate if the InitialsText is preferred over the Name.</documentation> </attribute> </extension> </simplecontent> </complextype> complextype NameTextType diagram <complextype name="nametexttype"> <documentation xml:lang="en">domain definition for the text of an individual name part.</documentation> <simplecontent> <restriction base="shr:bilingualtexttype"> <maxlength value="80"/> </restriction> </simplecontent> </complextype> simpletype GenderType <simpletype name="gendertype"> <documentation xml:lang="en">domain definition used, based on ISO 5218 codes for human sexes, to describe an Individual as a male or female for the administrative purposes of a program or service.</documentation> <appinfo>the recommended Gender codes can be found in the CDER table GENDER. These codes include: 0 - Not Known, 1 - Male, 2 - Female, and 9 - Not Specified.</appinfo> <restriction base="string"> <enumeration value="0"/> <enumeration value="1"/> <enumeration value="2"/> <enumeration value="9"/> </restriction> </simpletype> simpletype IndividualIDType <simpletype name="individualidtype"> <documentation xml:lang="en">domain definition for the Individual ID.</documentation> 42

43 <restriction base="pc:partyidtype"/> </simpletype> simpletype MaritalStatusType <simpletype name="maritalstatustype"> <documentation xml:lang="en">domain definition used to describe the legal marital status of an Individual. It does not indicate whether an Individual is in a common-law or other conjugal partnership.</documentation> <appinfo>the recommended Marital Status codes can be found in the CDER table MARITAL_STATUS. These codes include: N - Single (never married), M - Married, S - Separated, D - Divorced, and W - Widowed. </appinfo> <restriction base="string"> <enumeration value="n"/> <enumeration value="m"/> <enumeration value="s"/> <enumeration value="d"/> <enumeration value="w"/> </restriction> </simpletype> simpletype MilitaryServiceNumType <simpletype name="militaryservicenumtype"> <documentation xml:lang="en">domain definition for the Service Number assigned to a member of the Canadian Forces, such as F </documentation> <restriction base="string"> <maxlength value="9"/> </restriction> </simpletype> simpletype NameFormalityType <simpletype name="nameformalitytype"> <documentation xml:lang="en">domain definition for the formality of individual names.</documentation> <appinfo>the recommended Name Formality codes can be found in the CDER table NAME_FORMALITY. These codes include: Legal - Legal (registered with Office of the Registrar General), Formal - Formal (preferred for business), and Informal - Informal (nickname, alias).</appinfo> <restriction base="string"> <enumeration value="legal"/> <enumeration value="formal"/> <enumeration value="informal"/> </restriction> </simpletype> simpletype NameType <simpletype name="nametype"> <documentation xml:lang="en">domain definition for the types or positions of an individual Name Part such as Title, First Name, Generation Identifier.</documentation> <appinfo>valid name type codes can be found in the CDER table NAME_TYPE. These codes include: 10 - Preceding Title, 20 - Honorific Title, 30 - First Name, 40 - Middle Name, 50 - Last Name Prefix, 60 - Last Name, 70 - Alias, 80 - Generation ID, and 90 - Name Suffix.</appinfo> <restriction base="string"> <enumeration value="10"/> 43

44 <enumeration value="20"/> <enumeration value="30"/> <enumeration value="40"/> <enumeration value="50"/> <enumeration value="60"/> <enumeration value="70"/> <enumeration value="80"/> <enumeration value="90"/> </restriction> </simpletype> simpletype SocialInsuranceNumType <simpletype name="socialinsurancenumtype"> <documentation xml:lang="en">domain definition for the Social Insurance Number.</documentation> <restriction base="string"> <pattern value="[0-9]{9}"/> </restriction> </simpletype> GOOrganization Schema GOOrganization2.0.0.xsd TargetNamespace: Imported Namespace: GOOrganization2.0.0 GOShared2.0.0 GOCommonParty2.0.0 Complex types AdminOrganizationUnitType FederalBusinessIdentificationType FormalOrganizationType InformalOrganizationType NameTextType OntarioBusinessRegistrationType OrganizationNameType OrganizationType Simple types ActivityClassificationType BusinessRegistrationNumType JurisdictionType OntBusinessEstablishmentType OntBusinessStatusType OrganizationIDType OrganizationStructureType OrgNameFormalityType ProgramIdentifierType ReferenceNumType RegistrationNumType 44

45 complextype AdminOrganizationUnitType 45

46 Diagram 46

47 Source <complextype name="adminorganizationunittype"> <documentation xml:lang="en">a portion of a Formal Organization dedicated to a specific purpose, such as a department, branch or unit.</documentation> <complexcontent> <extension base="o:organizationtype"/> </complexcontent> </complextype> complextype FederalBusinessIdentificationType diagram <complextype name="federalbusinessidentificationtype" final="#all"> <documentation xml:lang="en">the Federal Business Identification is based on the 9-digit Business Registration Number issued by the Canada Customs and Revenue Agency, to uniquely identify a private sector entity or a public sector entity, a 2 letter Program Identifier to uniquely identify a government program, and a 4-digit Reference Number to uniquely identify an operating entity(ies) for that program.</documentation> <sequence> <element name="registrationnum" type="o:registrationnumtype"> <documentation xml:lang="en">a unique identifier of a private or public sector entity. Assigned by the Canada Revenue Agency. It is also known as Business Number.</documentation> <element name="programid" type="o:programidentifiertype"> <documentation xml:lang="en">a unique identifier of a government program, assigned by the Canada Customs and Revenue Agency.</documentation> <element name="referencenum" type="o:referencenumtype"> 47

48 <documentation xml:lang="en">a unique identifier of one operating entity, designated by the Business Number registrant, to undertake program-specific dealings with the Government on the registrant's behalf. A registrant may choose to designate separate or numerous operating entities for each program. Each such operating entity will be identified by a reference number that is program-specific. </documentation> </sequence> </complextype> 48

49 complextype FormalOrganizationType 49

50 diagram 50

51 <complextype name="formalorganizationtype"> <documentation xml:lang="en">a legally-constituted Organization, such as a corporation, partnership, sole proprietorship or public sector institution. It includes Government of Ontario ministries and agencies, and organizations in the broader public sector such as municipalities, universities, colleges, schools and hospitals.</documentation> <appinfo>1. A Formal Organization may have zero or one (not many) Ontario Business Registrations, except that it may have multiple additional name registrations with Establishment Type Code AN or PN. 2. A Formal Organization may have zero or one (not many) Registration Numbers, the 9 digit portion of the Federal Business Identification.</appinfo> <complexcontent> <extension base="o:organizationtype"> <sequence> <element name="fiscalyearendmonthday" type="shr:monthday" minoccurs="0"> <documentation xml:lang="en">the month and day when the Organization's fiscal (financial) year ends.</documentation> <element name="activityclassificationcode" type="o:activityclassificationtype" minoccurs="0"> <documentation xml:lang="en">a code used to indicate the main activity of the Organization.</documentation> <element name="organizationtypecode" type="o:organizationstructuretype" minoccurs="0"> <documentation xml:lang="en">a code used to indicate the type of an Organization.</documentation> <element name="federalbusinessid" type="o:federalbusinessidentificationtype" minoccurs="0" maxoccurs="unbounded"> <documentation xml:lang="en">an Organization may have zero or many Federal Business Identifications.</documentation> <element name="ontbusinessregistration" type="o:ontariobusinessregistrationtype" minoccurs="0" maxoccurs="unbounded"> <documentation xml:lang="en">an Organization may have zero or many Ontario Business Registrations.</documentation> <choice minoccurs="0"> <element name="incorporatedcountrycode" type="shr:iso3166-1alpha2countrycodetype"> <documentation xml:lang="en">the two-letter ISO :1997 Country Code for a country in which the organization is registered.</documentation> <appinfo>the country code should be validated against the CDER table COUNTRY.</appinfo> <element name="incorporatedprovincestatecode" type="shr:canadapostprovincestatecodetype"> <documentation xml:lang="en">the two-letter Canada Post Province, State codes for a province, territory, or state in which the organization is registered.</documentation> <appinfo>the province state code should be validated against the CDER table PROVINCE_STATE.</appinfo> </choice> </sequence> <attribute name="jurisdictiontype" type="o:jurisdictiontype" use="optional"> <documentation xml:lang="en">a code used to indicate the type of jurisdiction in which the organization is registered.</documentation> </attribute> </extension> </complexcontent> </complextype> 51

52 complextype InformalOrganizationType 52

53 diagram 53

54 <complextype name="informalorganizationtype"> <documentation xml:lang="en">a set of Individuals that is not legally-constituted, but which has a single contact point and possibly a leader. Examples: a family, a committee, a class of students, an unincorporated association.</documentation> <complexcontent> <extension base="o:organizationtype"/> </complexcontent> </complextype> complextype NameTextType diagram <complextype name="nametexttype"> <documentation xml:lang="en">domain definition for organization name or abbreviation text.</documentation> <simplecontent> <restriction base="shr:bilingualtexttype"/> </simplecontent> </complextype> complextype OntarioBusinessRegistrationType diagram <complextype name="ontariobusinessregistrationtype" final="#all"> <documentation xml:lang="en">an Organization's registration with the Ministry of Consumer and Business Services to do business in Ontario. The business may be registered as a corporation or a small business (partnership or sole proprietorship) in the ONBIS (Ontario Business Information System) database.</documentation> <sequence> <element name="businessregistrationnum" type="o:businessregistrationnumtype"> <documentation xml:lang="en">the identifier of the business in the ONBIS system. Also known as the Establishment Identification Number.</documentation> <appinfo>for corporations: "C" + 7 characters, the Ontario Corporation Number For small (unincorporated) businesses: "B" + 9 characters, the Business Identification Number For archived businesses: "A" + the OCN or the BIN.</appinfo> <element name="establishmenttypecode" type="o:ontbusinessestablishmenttype" minoccurs="0"> 54

55 <documentation xml:lang="en">the type of business as registered by ONBIS.</documentation> <element name="statuscode" type="o:ontbusinessstatustype" minoccurs="0"> <documentation xml:lang="en">a code used to indicate the status of the business registration in ONBIS, such as active, inactive, cancelled or dissolved.</documentation> </sequence> </complextype> complextype OrganizationNameType diagram <complextype name="organizationnametype"> <documentation xml:lang="en">a name used to identify an Organization for legal or operational purposes.</documentation> <sequence> <element ref="o:name"> <documentation xml:lang="en">the full text of the name or abbreviation used to identify the Organization.</documentation> <sequence minoccurs="0"> <element ref="pc:startdate"> <documentation xml:lang="en">the date when the Organization starts to use this name.</documentation> <appinfo>data Integrity Rule: 1. IF EndDate of OrganizationNameType is used THEN StartDate of OrganizationNameType must also be used.</appinfo> <element ref="pc:enddate" minoccurs="0"> <documentation xml:lang="en">the date when the Organization ceases to use this name.</documentation> <appinfo>data Integrity Rule: 1. IF EndDate of OrganizationNameType has a value THEN EndDate of OrganizationNameType must be >= StartDate of OrganizationNameType.</appinfo> </sequence> </sequence> <attribute name="formality" type="o:orgnameformalitytype"> <documentation xml:lang="en">a code used to indicate the appropriate usage of the name.</documentation> </attribute> </complextype> 55

56 complextype OrganizationType 56

57 diagram 57