information standard for party and party contact ... · pdf fileinformation standard for party...

© Queen's Printer for Ontario, 2005.

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. 27.2

Version 2.0.0 Status: Approved

OCCIO/OCCTO MANAGEMENT BOARD SECRETARIAT CORPORATE ARCHITECTURE AND STANDARDS BRANCH TECHNICAL STANDARDS SECTION

Last Review Date: Feb 8

th, 2005

GO-ITS 27.2 Status: Approved Version 2.0.0

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.


3

Table Of Contents

INTRODUCTION ................................................................................................................................5 1 Introduction to GOCDES 2.0.0 .........................................................................................................5

1.1 Applicability ..................................................................................................................................6 1.2 Requirement Levels ...................................................................................................................6 1.3 Document Types and Filenames ..............................................................................................6 1.4 Purpose of the Standard ............................................................................................................6 1.5 Recommended Versioning and/or Change Management ....................................................6 1.6 Contact Information ....................................................................................................................7 1.7 Type of Standard ........................................................................................................................7 1.8 Acknowledgements ....................................................................................................................8

1.8.1 Development Team ............................................................................................................8 1.8.2 Reviewers ............................................................................................................................8 1.8.3 Group and Committee Reviews ........................................................................................9

COMMON DATA ELEMENTS XML SCHEMAS ............................................................................ 10 2 CDES Logical Design....................................................................................................................... 10

2.1 Design Principles ...................................................................................................................... 10 2.2 CDES Party and Party Contact Sub Areas ........................................................................... 11 2.3 CDES Party and Party Contact Data Models ....................................................................... 12

2.3.1 Party Common .................................................................................................................. 12 2.3.2 Party Contact ..................................................................................................................... 13 2.3.3 Individual ............................................................................................................................ 14 2.3.4 Organization ...................................................................................................................... 15

3 GOCDES Physical Design .............................................................................................................. 17 3.1 XML Schema Namespaces ..................................................................................................... 17 3.2 XML Schemas ........................................................................................................................... 17

3.2.1 GOPartyCommon ............................................................................................................. 17 3.2.2 GOPartyContact ................................................................................................................ 31 3.2.3 GOIndividual ...................................................................................................................... 32 3.2.4 GOOrganization ................................................................................................................ 41

4 Usage Rules ...................................................................................................................................... 58 4.1 General GOCDES Usage Rules ............................................................................................ 58 4.2 GOCDES 2.0.0 Party and Party Contact Schema Usage Rules ....................................... 59

Errata .......................................................................................................................................................... 61 Document Numbering .............................................................................................................................. 62 Copyright .................................................................................................................................................... 63

APPENDIX A: ADDITIONAL INFORMATION ............................................................................... 64 Abbreviations and Acronyms .................................................................................................................. 64 Change Control ......................................................................................................................................... 65

Technical Standards Change Control Process ................................................................................ 65 Change Control Procedure ................................................................................................................. 65 Change Control Documentation ......................................................................................................... 66

GOCDES 2.0.0 Change Record ............................................................................................................. 68 Known Issues ............................................................................................................................................ 69 List of Related Documents ...................................................................................................................... 70 References ................................................................................................................................................ 71


4

Table Of Figures

Figure 1 CDES Subject Areas Overview......................................................................................... 11 Figure 2 Party Subject Area Overview ............................................................................................ 11 Figure 3 Address Subject Area Overview ....................................................................................... 12 Figure 4 Party Common Logical Data Model .................................................................................. 13 Figure 5 Party Contact Logical Data Model .................................................................................... 14 Figure 6 Individual Logical Data Model ........................................................................................... 15 Figure 7 Organization Logical Data Model ...................................................................................... 16 Figure 8 Party and Party Contact Namespaces .............................................................................. 17 Figure 9 Extension of Party Role .................................................................................................... 59 Figure 10 Example of N-ary Relationships between Parties .......................................................... 60


5

Introduction

1 Introduction to GOCDES 2.0.0 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 2.0.0 is developed based on Common Data Element Model (CDEM) Party Business View Logical Data Model (BVLDM) version 2.0.0 [see Related Documents 1], which was approved by Corporate Architecture Review Board in May 2004. 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 27.0. Another earlier release of GOCDES [see Related Document 5], the GOCDES Address version 2.0.0 that was adopted as GO-ITS 27.1, covers only the Address subject area. The design of GOCDES version 2.0.0 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 source 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 2.0.0 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 2.0.0 Physical Design, which is composed of the definition of GOCDES 2.0.0 namespaces, XML Schema tree diagrams, and fragments of the GOCDES 2.0.0 XML Schema source 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 2.0.0 Usage Rules. These rules indicate mandatory and optional parts of the standard, as well as recommendations on how to use GOCDES 2.0.0 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.


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 http://intra.pmed.mbs.gov.on.ca/mbc/pdf/Agency_Establishment&Accountability-Dir.pdf 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 Type

GO-ITS Government of Ontario Information Technology Standard

File name: GO-ITS 27.2 IT Standard Version 2.0.0.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, e-mail 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 sources.

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


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) 212-0940

E-mail [email protected]

1.7 Type of Standard

Check

One 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.).

X 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


8

1.8 Acknowledgements

1.8.1 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

1.8.2 Reviewers

Name Cluster/Ministry Branch

Ajay Muppidi Land Resources Cluster, Ministry of Environment

Business Service and Solution Branch

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 Finance

Enterprise Technology Solutions Branch

Fred Woodhall Land Resources Cluster, Ministry of Agriculture and Foods

Information Technology and Services

Garry Stoddart Transportation Cluster Information Resources Management

Gennaro Giampaolo Economics and Business Cluster Planning & Architecture

George Berelidze Economics and Business Cluster Planning & Architecture

George Silva Land Resources Cluster, Ministry of Natural Resources

Business Solution and Forest

Greg Bay Land Resources Cluster, Ministry of Natural Resources

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 Resources Cluster, Ministry of Natural Resources

Land and Resources Data Administration

Lorie Oblak Transportation Cluster Strategic Planning and Architecture


9

Moira Watson-Turner Land Resources Cluster Consultant to Land and Resources Data Administration

Murray Edmund Economics and Business Cluster Planning & Architecture

Norman Lee Management Board Secretariat Corporate Architecture and Standards Branch

Saumitra Hore Land Resources Cluster, Ministry of Environment

Information Management and Technology Branch

Simon Loban Community Services Cluster, Ministry of Education

Business Planning & Expenditure Management Branch

Sylvia Smart Management Board Secretariat Corporate Architecture and Standards Branch

1.8.3 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


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 416-327-0313.

2.1 Design Principles

This section lists the design principles that guided development of GOCDES 2.0.0. 1. 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).


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


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).

2.3.1 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.


13

OntOf f icialLanguageTy pe

English = en

French = f r

<<enumeration>>

Rule 1: if exist (EndDate) then

ex ist (Start Dat e)

Rule 2: If exist (EndDate) then

EndDate >= St artDate

Party RelationshipCodeTy pe

Member of = MemberOf

Represented by = RepresentedBy

Owned by = OwnedBy

Suc ces sor o f = Succ ess orOf

Par t o f = Par tOf

Linked t o = L inkedTo

<<enum eration>>

FlagTy pe

Yes = Yes

No = No

<<enumeration>>

Party Role Relationship

<<att>> ty peCode : Party RelationshipCodeTy pe

<<elt>> StartDate [0..1] : Date

<<elt>> EndDate [0..1] : Date

<<complexTy pe>>

Role

<<elt>> Name : RoleNam eTy pe

<<elt>> Code [ 0..1] : RoleCodeTy pe

<<elt>> Desc [ 0..1] : DescriptionTextTy pe

<<complexTy pe>>

Party Role



<<complexTy pe>>

1

0..*

+SubjectRole1

+SubjectRoleRelationship0..*

1

0..*

+ObjectRole

1

+ObjectRoleRelationship 0..*

0..* 10..*

+Role

1

described by

Party Relationship

<<att>> ty peCode : Party RelationshipCodeTy pe



<<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

<<complexTy pe>>

1

1. .*

+Party1

+Party Role1. .*

plays

0..*

1+Subjec tRelations hip

0..*+Subject

1

0. .*

1+ObjectRelationship

0. .*+Object

1

0. .*0..*

+Subject0. .*

relates to

+Object

0..*

Ownership Relationship

<<elt>> Ownership Percent [0..1] : PercentageTy pe

<<complexTy pe>>

Figure 4 Party Common Logical Data Model

2.3.2 Party Contact

Figure 5 shows Party Contact logical data model.


14

ContactAddressUsageType Business = Business Personal = Personal Vacation = Vacation

<<enumeration>> ContactPurposeType

Billing = Billing General Contact = General Shipping and Delivering = Shipping

<<enumeration>> ContactTimeType

Weekdays = Day Evenings = Evening Weekends and holidays = Weekend

<<enumeration>>

OntOfficialLanguageType English = en French = fr

<<enumeration>> FlagType

Yes = Yes No = No

<<enumeration>>

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

Address <<elt>> ValidStartDate [0..1] : Date <<elt>> ValidEndDate [0..1] : Date

<<complexType>>

Role <<elt>> Name : RoleNameType <<elt>> Code [0..1] : RoleCodeType <<elt>> Desc [0..1] : DescriptionTextType

<<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

<<complexType>>

0..*

1..*

0..1

+Address 1..*

located at

Party <<elt>> ProgramPartyID [0..1] <<elt>> PreferredOfficialLanguageCode [0..1] : OntOfficialLanguageType <<elt>> PreferredLanguageCode [0..1] : ISO639-1LanguageType <<att>> firstNationsStatusFlag [0..1] : FlagType

<<complexType>>

0..*

0..*

+Subject

0..*

relates to +Object 0..*

Party Role <<elt>> StartDate [0..1] : Date <<elt>> EndDate [0..1] : Date

<<complexType>>

1

0..*

+Role 1

0..* described by

0..*

1

+PartyRoleAddress 0..*

1

contact at

1

1..*

+Party 1

+PartyRole 1..* plays

Contact List <<elt>> Desc [0..1] : DescriptionTextType

<<complexType>>

0..*

+PartyRole 0..*

contains

Figure 5 Party Contact Logical Data Model

2.3.3 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


15

Rule 2: if exist (EndDate) then exist (StartDate)

Rule 3: If exist (EndDate) then EndDate >= StartDate

Rule 1: if exist (BirthDate) & exist (DeathDate) then DeathDate >= BirthDate

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)

GenderType Not Known = 0 Male = 1 Female = 2 Not Specified = 9

<<enumeration>>

MaritalStatusType Single = N Married = M Separated = S Divorced = D Widowed = W

<<enumeration>>

NameFormalityType Legal Name = Legal Formal Name = Formal Informal Name = Informal

<<enumeration>>

FlagType Yes = Yes No = No

<<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

<<enumeration>> 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 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

<<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

<<complexType>>

0..* +LanguageSkill 0..*

uses

0..* +IndividualName 0..* named by

OntOfficialLanguageType English = en French = fr

<<enumeration>>

Party <<elt>> ProgramPartyID [0..1] <<elt>> PreferredOfficialLanguageCode [0..1] : OntOfficialLanguageType <<elt>> PreferredLanguageCode [0..1] : ISO639-1LanguageType <<att>> firstNationsStatusFlag [0..1] : FlagType

<<complexType>>

0..*

0..*

+Subject 0..*

relates to +Object 0..*

Figure 6 Individual Logical Data Model

2.3.4 Organization

An Organization is a group of Individuals that has allocated resources. 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


16

Informal Organization

<<complexType>>Admin Organization Unit

<<complexType>>

Rule 1: if exist (EndDate) then

exist (StartDate)

Rule 2: If exist (EndDate) then

EndDate >= StartDate

OrgNameFormalityType

Legal = Legal

Operating, Trade, Sty le, 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

<<enumeration>>Organization Name

<<att>> formalityCode : OrgNameFormalityType

<<att>> Of ficiallanguageCode : OntOf f icialLanguageType

<<elt>> Name : OrgNameTextType



<<complexType>>

Organization

<<elt>> Name [0..1] : OrgNameTextType

<<elt>> Activ ityDesc [0..1] : DescriptionTextType



<<complexType>>

0..*

+OrganizationName

0..*named by

JurisdictionType

Federal level jurisdiction = Federal

Provincial, State, or Territorial level Jurisdiction = Province

<<enumeration>>

OntOf f icialLanguageType

English = en

French = f r

<<enumeration>>FlagType

Yes = Yes

No = No

<<enumeration>>

Party

<<elt>> ProgramPartyID [0..1]

<<elt>> PreferredOf f icialLanguageCode [0..1] : OntOf f icialLanguageType

<<elt>> PreferredLanguageCode [0..1] : ISO639-1LanguageType

<<att>> f irstNationsStatusFlag [0..1] : FlagType

<<complexType>>

0..*

0..*

+Subject

0..*

relates to

+Object0..*

Federal Business Identif ication

<<elt>> RegistrationNum : RegistrationNumType

<<elt>> ProgramID : ProgramIdentif ierType

<<elt>> ReferenceNum : ReferenceNumType

<<complexType>>Ontario Business Registration

<<elt>> BusinessRegistrationNum : BusinessRegistrationNumType

<<elt>> EstablishmentTypeCode [0..1] : BusinessEstablishmentType

<<elt>> StatusCode [0..1] : BusinessStatusType

<<complexType>>

Formal Organization

<<elt>> FiscalYearEndMonthDay [0. .1] : MonthDayType

<<elt>> Activ ityClassif icationCode [0..1] : Activ ityClassificationType

<<elt>> OrganizationTypeCode [0..1] : OrganizationStructureType

<<complexType>>

0..*+FederalBusinessID 0..*

identified by

0..* +OntBusinessRegistration0..*

registered as

Incorporation Province State

<<elt>> ProvinceStateCode : CanadaPostProvinceStateCodeType

<<complexType>>

Incorporation Country

<<elt>> CountryCode : ISO3166-1CountryCodeType

<<complexType>>

Incorporation Jurisdiction Choice

<<att>> jurisdictionTypeCode : JurisdictionType

<<choice>>

0..11 0..11

determined by

jurisdictionTypeCode in ('Province', 'State' 'Territory ')

jurisdictionTypeCode = 'Federal'

Rule 3: if exist (Incorporation Jurisdiction Choice) then

OrganizationTypeCode = '03'

Figure 7 Organization Logical Data Model


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

3.2.1 GOPartyCommon


18

Schema GOCommonParty2.0.0.xsd TargetNamespace: GOCommonParty2.0.0 Imported Namespace: GOShared2.0.0 GOCommonAddress2.0.0 Complex types Simple types

OwnershipRelationshipType ContactAddressUsageType

PartyRelationshipType ContactPurposeType

PartyRoleAddressType ContactTimeType

PartyRoleRelationshipType PartyIDType

PartyRoleType PartyRelationshipCodeType

PartyType RoleCodeType

RoleNameType

RoleType

Schema GOCommonParty2.0.0.xsd complexType OwnershipRelationshipType

diagram

source <complexType name="OwnershipRelationshipType"> <annotation> <documentation xml:lang="EN">Define Ownership Relationship as a special type of Party Relationship by extending the Party Relationship.</documentation> </annotation> <complexContent> <extension base="pc:PartyRelationshipType"> <sequence> <element name="OwnershipPercent" type="shr:PercentageType" minOccurs="0"> <annotation>


19

<documentation xml:lang="EN">The percentage of ownership of one organization. </documentation> </annotation> </element> </sequence> </extension> </complexContent> </complexType>

complexType PartyRelationshipType

diagram

source <complexType name="PartyRelationshipType"> <annotation> <documentation xml:lang="EN">Definition of an associated relationship between two Parties</documentation> </annotation> <sequence> <element ref="pc:Subject" minOccurs="0"> <annotation> <documentation xml:lang="EN">Information about the Subject (or Primary) Party in a party to party association relationship.</documentation> </annotation> </element> <element ref="pc:Object" minOccurs="0"> <annotation> <documentation xml:lang="EN">Information about the Object (or Secondary) Party in a party to party association relationship.</documentation> </annotation> </element> <sequence minOccurs="0"> <element ref="pc:StartDate"> <annotation> <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> </annotation> </element> <element ref="pc:EndDate" minOccurs="0"> <annotation> <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> </annotation> </element>


20

</sequence> </sequence> <attribute ref="pc:type" use="required"> <annotation> <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> </annotation> </attribute> </complexType>


21

complexType PartyRoleAddressType


22

diagram


23

source <complexType name="PartyRoleAddressType"> <annotation> <documentation xml:lang="EN">An association of a Party Role to an Address for a time period and purpose.</documentation> </annotation> <sequence> <sequence minOccurs="0"> <element ref="pc:StartDate"> <annotation> <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> </annotation> </element> <element ref="pc:EndDate" minOccurs="0"> <annotation> <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> </annotation> </element> </sequence> <sequence minOccurs="0"> <element name="EffectiveStartMonthDay" type="shr:MonthDay" minOccurs="0"> <annotation> <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> </annotation> </element> <element name="EffectiveEndMonthDay" type="shr:MonthDay" minOccurs="0"> <annotation> <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> </annotation> </element> </sequence> <sequence minOccurs="0"> <element name="Invalid" type="shr:FlagType" default="No" minOccurs="0"> <annotation> <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, email 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> </annotation> </element> <element name="InvalidDate" type="shr:Date" minOccurs="0"> <annotation> <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, email 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> </annotation> </element> </sequence> <element ref="ac:Address" minOccurs="0" maxOccurs="unbounded">


24

<annotation> <documentation xml:lang="EN">A mandatory association between Contact to Address.</documentation> </annotation> </element> </sequence> <attribute name="usageType" type="pc:ContactAddressUsageType" use="optional"> <annotation> <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> </annotation> </attribute> <attribute name="contactPurpose" type="pc:ContactPurposeType" use="optional"> <annotation> <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> </annotation> </attribute> <attribute name="contactTime" type="pc:ContactTimeType" use="optional"> <annotation> <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> </annotation> </attribute> <attribute name="priorityNum" type="shr:SequenceNumType" use="optional" default="1"> <annotation> <documentation xml:lang="EN">A number that indicates a priority sequence of Addresses for contacting a Party (Role).</documentation> </annotation> </attribute> <attribute name="temp" type="shr:FlagType" use="optional" default="No"> <annotation> <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> </annotation> </attribute> </complexType>


25

complexType PartyRoleRelationshipType

diagram

source <complexType name="PartyRoleRelationshipType"> <annotation> <documentation xml:lang="EN">Definition of an associated relationship between two Parties or two Party Roles.</documentation> </annotation> <sequence> <element name="SubjectRole" type="pc:PartyRoleType" minOccurs="0"> <annotation> <documentation xml:lang="EN">Information about the Subject (or Primary) Role in a party role to party role association relationship.</documentation> </annotation> </element> <element name="ObjectRole" type="pc:PartyRoleType" minOccurs="0"> <annotation> <documentation xml:lang="EN">Information about the Object (or Secondary) Role in a party role to party role association relationship.</documentation> </annotation> </element> <sequence minOccurs="0"> <element ref="pc:StartDate"> <annotation> <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> </annotation> </element> <element ref="pc:EndDate" minOccurs="0"> <annotation> <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> </annotation> </element> </sequence> </sequence> <attribute ref="pc:type" use="required"> <annotation> <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> </annotation>


26

</attribute> </complexType>

complexType PartyRoleType

diagram

source <complexType name="PartyRoleType"> <annotation> <documentation xml:lang="EN">An association between a Party and a Role to signify that this Party plays this specific role.</documentation> </annotation> <sequence> <element ref="pc:Role"> <annotation> <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


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> </annotation> </element> <element ref="pc:Party" minOccurs="0"> <annotation> <documentation xml:lang="EN">The information about the Party that plays the specific role.</documentation> </annotation> </element> <element ref="pc:PartyRoleAddress" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation xml:lang="EN">This party role may have zero, one or many Addresses</documentation> </annotation> </element> <element name="SubjectRoleRelationship" type="pc:PartyRoleRelationshipType" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation xml:lang="EN">Information about the Subject (or Primary) Role in a party role to party role association relationship.</documentation> </annotation> </element> <element name="ObjectRoleRelationship" type="pc:PartyRoleRelationshipType" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation xml:lang="EN">Information about the Object (or Secondary Role in a party role to party role association relationship.</documentation> </annotation> </element> <sequence minOccurs="0"> <element ref="pc:StartDate"> <annotation> <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> </annotation> </element> <element ref="pc:EndDate" minOccurs="0"> <annotation> <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> </annotation> </element> </sequence> </sequence> </complexType>


28

complexType PartyType


29

diagram


30

source <complexType name="PartyType"> <annotation> <documentation xml:lang="EN">An Individual or Organization, as identified and described by a program or service.</documentation> </annotation> <sequence> <element ref="pc:ProgramPartyID" minOccurs="0"> <annotation> <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> </annotation> </element> <element name="PreferredOfficialLanguageCode" type="shr:OntOfficialLanguageType" minOccurs="0"> <annotation> <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> </annotation> </element> <element name="PreferredLanguageCode" type="shr:ISO639-1LanguageCodeType" minOccurs="0"> <annotation> <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> </annotation> </element> <element ref="pc:PartyRole" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation xml:lang="EN">This party may play one or many party roles.</documentation> </annotation> </element> <element ref="pc:Subject" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation xml:lang="EN">This party may be a Subject in a recursive Party to Party relationship.</documentation> </annotation> </element> <element ref="pc:Object" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation xml:lang="EN">This party may be an Object in a recursive Party to Party relationship.</documentation> </annotation> </element> <element name="SubjectRelationship" type="pc:PartyRelationshipType" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation xml:lang="EN">Information about the Subject (or Primary) Relationship in a party to party association relationship.</documentation> </annotation> </element> <element name="ObjectRelationship" type="pc:PartyRelationshipType" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation xml:lang="EN">Information about the Object (or Secondary) Relationship in a party to party association relationship.</documentation> </annotation> </element> </sequence> <attribute name="firstNationsStatus" type="shr:FlagType" use="optional" default="No"> <annotation> <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> </annotation> </attribute> </complexType>


31

complexType RoleNameType

diagram

source <complexType name="RoleNameType"> <annotation> <documentation xml:lang="EN">Domain definition for a name or identifier that identifies the role an organization or an individual plays.</documentation> </annotation> <simpleContent> <restriction base="shr:BiLingualTextType"> <maxLength value="30"/> </restriction> </simpleContent> </complexType>

complexType RoleType

diagram

source <complexType name="RoleType"> <annotation> <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> </annotation> <sequence> <element name="Name" type="pc:RoleNameType"> <annotation> <documentation xml:lang="EN">A name for the role identified by the associated RoleCode an organization or an individual plays.</documentation> </annotation> </element> <element name="Code" type="pc:RoleCodeType" minOccurs="0"> <annotation> <documentation xml:lang="EN">A code that indentifies a role an organization or an individual plays.</documentation> </annotation> </element> <element name="Desc" type="shr:DescriptionTextType" minOccurs="0">


32

<annotation> <documentation xml:lang="EN">A text that describes the role identified by the RoleCode an organization or an individual plays.</documentation> </annotation> </element> </sequence> </complexType>

simpleType ContactAddressUsageType

source <simpleType name="ContactAddressUsageType"> <annotation> <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> </annotation> <restriction base="string"> <enumeration value="Business"/> <enumeration value="Person"/> <enumeration value="Vacation"/> </restriction> </simpleType>

simpleType ContactPurposeType

source <simpleType name="ContactPurposeType"> <annotation> <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> </annotation> <restriction base="string"> <enumeration value="Billing"/> <enumeration value="General"/> <enumeration value="Shipping"/> </restriction> </simpleType>

simpleType ContactTimeType

source <simpleType name="ContactTimeType"> <annotation> <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> </annotation> <restriction base="string"> <enumeration value="Day"/> <enumeration value="Evening"/> <enumeration value="Weekend"/> </restriction> </simpleType>

simpleType PartyIDType

source <simpleType name="PartyIDType"> <annotation> <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>


33

</annotation> <restriction base="shr:IDType"/> </simpleType>

simpleType PartyRelationshipCodeType

source <simpleType name="PartyRelationshipCodeType"> <annotation> <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> </annotation> <restriction base="string"/> </simpleType>

simpleType RoleCodeType

source <simpleType name="RoleCodeType"> <annotation> <documentation xml:lang="EN">Domain definition for a code that indentifies a role an organization or an individual plays.</documentation> </annotation> <restriction base="string"> <maxLength value="2"/> </restriction> </simpleType>

3.2.2 GOPartyContact

Schema GOContact2.0.0.xsd TargetNamespace: GOContact2.0.0 Imported Namespace: 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 Complex types Simple types

ContactType

complexType ContactType

diagram

source <complexType name="ContactType"> <annotation>


34

<documentation xml:lang="EN">An association of a purpose and one or many Party Role Addresses</documentation> </annotation> <sequence> <element name="Desc" type="shr:DescriptionTextType" minOccurs="0"/> <element ref="pc:PartyRole" maxOccurs="unbounded"/> </sequence> </complexType>

3.2.3 GOIndividual

Schema GOIndividual2.0.0.xsd TargetNamespace: GOIndividual2.0.0 Imported Namespace: GOShared2.0.0 GOCommonParty2.0.0 Complex types Simple types

HeightType GenderType

HonorificType IndividualIDType

IndividualNamePartType MaritalStatusType

IndividualType MilitaryServiceNumType

LanguageSkillType NameFormalityType

NameInitialsTextType NameType

NameInitialUsageType SocialInsuranceNumType

NameTextType

complexType HeightType

diagram

source <complexType name="HeightType"> <annotation> <documentation xml:lang="EN">Domain definition used to describe the height of an individual, expressed in centimetres.</documentation> </annotation> <simpleContent> <restriction base="shr:LengthType"> <minInclusive value="0.00"/> </restriction> </simpleContent> </complexType>

complexType HonorificType

diagram

source <complexType name="HonorificType"> <annotation> <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>


35

</annotation> <simpleContent> <restriction base="shr:BiLingualTextType"/> </simpleContent> </complexType>

complexType IndividualNamePartType

diagram

source <complexType name="IndividualNamePartType"> <annotation> <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> </annotation> <sequence> <element name="Name" type="i:NameTextType" minOccurs="0"> <annotation> <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> </annotation> </element> <element name="InitialsText" type="i:NameInitialsTextType" minOccurs="0"> <annotation> <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> </annotation> </element> <sequence minOccurs="0"> <element ref="pc:StartDate"> <annotation> <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>


36

</annotation> </element> <element ref="pc:EndDate" minOccurs="0"> <annotation> <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> </annotation> </element> </sequence> </sequence> <attribute name="formality" type="i:NameFormalityType" use="required"> <annotation> <documentation xml:lang="EN">A code used to indicate the appropriate usage of the name.</documentation> </annotation> </attribute> <attribute name="typeCode" type="i:NameType" use="required"> <annotation> <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> </annotation> </attribute> <attribute name="groupNum" type="shr:SequenceNumType" use="required"> <annotation> <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> </annotation> </attribute> <attribute name="sequenceNum" type="shr:SequenceNumType" use="optional"> <annotation> <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> </annotation> </attribute> <attribute name="preferred" type="shr:FlagType" use="optional"> <annotation> <documentation xml:lang="EN">A Flag to indicate if this Name Part is preferred for use.</documentation> </annotation> </attribute> </complexType>


37

complexType IndividualType


38

diagram


39

source <complexType name="IndividualType"> <annotation> <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> </annotation> <complexContent> <extension base="pc:PartyType"> <sequence> <element name="HonorificTitle" type="i:HonorificType" minOccurs="0"> <annotation> <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> </annotation> </element> <element name="GivenName" type="i:NameTextType" minOccurs="0"> <annotation> <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> </annotation> </element> <element name="LastName" type="i:NameTextType" minOccurs="0"> <annotation> <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> </annotation> </element> <element name="FormerLastName" type="i:NameTextType" minOccurs="0"> <annotation> <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> </annotation> </element> <element name="IndividualName" type="i:IndividualNamePartType" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation xml:lang="EN">A part of an Individual's name or an associated honorific title, expressed in full or as an initial. </documentation> </annotation> </element> <element name="BirthDate" type="shr:Date" minOccurs="0"> <annotation> <documentation xml:lang="EN">The date of birth of an Individual. </documentation> </annotation> </element> <element name="DeathDate" type="shr:Date" minOccurs="0"> <annotation> <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> </annotation> </element> <element name="GenderCode" type="i:GenderType" minOccurs="0"> <annotation> <documentation xml:lang="EN">The gender code of an Individual based on ISO 5218 codes for human sexes.</documentation> </annotation> </element> <element name="LegalMaritalStatusCode" type="i:MaritalStatusType" minOccurs="0"> <annotation> <documentation xml:lang="EN">A code used to describe the legal marital status of an Individual.</documentation> </annotation> </element> <element name="Height" type="i:HeightType" minOccurs="0">


40

<annotation> <documentation xml:lang="EN">A integer used to describe the height of an individual, expressed in centimetres.</documentation> </annotation> </element> <element name="PositionTitle" type="i:NameTextType" minOccurs="0"> <annotation> <documentation xml:lang="EN">The name of the job or position occupied by the Individual within an Organization.</documentation> </annotation> </element> <element name="SignatureImage" type="base64Binary" minOccurs="0"> <annotation> <documentation xml:lang="EN">A graphic depiction of the Individual's handwritten signature on documents.</documentation> </annotation> </element> <element name="PhotoImage" type="base64Binary" minOccurs="0"> <annotation> <documentation xml:lang="EN">A photographic representation of an Individual for the identification or adminstrative purposes of the program or service.</documentation> </annotation> </element> <element name="SocialInsuranceNum" type="i:SocialInsuranceNumType" minOccurs="0"> <annotation> <documentation xml:lang="EN">The Social Insurance Number assigned to an Individual by the Government of Canada.</documentation> </annotation> </element> <element name="LanguageSkill" type="i:LanguageSkillType" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation>A list of language skills an Individual has.</documentation> </annotation> </element> </sequence> </extension> </complexContent> </complexType>

complexType LanguageSkillType

diagram

source <complexType name="LanguageSkillType"> <annotation> <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> </annotation> <sequence> <element name="Name" type="shr:ISO639-1LanguageType"> <annotation> <documentation xml:lang="EN">A code used to describe a major languages used in the world.</documentation>


41

</annotation> </element> </sequence> <attribute name="code" type="shr:ISO639-1LanguageCodeType" use="required"> <annotation> <documentation xml:lang="EN">A code used to describe a major languages used in the world.</documentation> </annotation> </attribute> <attribute name="peferredOfficial" type="shr:FlagType" use="optional"> <annotation> <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> </annotation> </attribute> <attribute name="peferred" type="shr:FlagType" use="optional"> <annotation> <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> </annotation> </attribute> <attribute name="firstLearned" type="shr:FlagType" use="optional"> <annotation> <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> </annotation> </attribute> <attribute name="speak" type="shr:FlagType" use="optional"> <annotation> <documentation xml:lang="EN">A flag to indicate whether the individual can speak the Language identified by the LanguageCode.</documentation> </annotation> </attribute> <attribute name="read" type="shr:FlagType" use="optional"> <annotation> <documentation xml:lang="EN">A flag to indicate whether the individual can read in the Language identified by the LanguageCode.</documentation> </annotation> </attribute> <attribute name="write" type="shr:FlagType" use="optional"> <annotation> <documentation xml:lang="EN">A flag to indicate whether the individual can write in the Language identified by the LanguageCode.</documentation> </annotation> </attribute> </complexType>

complexType NameInitialsTextType

diagram

source <complexType name="NameInitialsTextType"> <annotation> <documentation xml:lang="EN">Domain definition for individual name initials text.</documentation> </annotation> <simpleContent> <restriction base="i:NameInitialUsageType"> <maxLength value="5"/> </restriction> </simpleContent> </complexType>


42

complexType NameInitialUsageType

diagram

source <complexType name="NameInitialUsageType"> <annotation> <documentation xml:lang="EN">Domain definition for individual name initials usage.</documentation> </annotation> <simpleContent> <extension base="string"> <attribute name="initialUsed" type="shr:FlagType" use="optional" default="Yes"> <annotation> <documentation xml:lang="EN">A Flag to indicate if the InitialsText is preferred over the Name.</documentation> </annotation> </attribute> </extension> </simpleContent> </complexType>

complexType NameTextType

diagram

source <complexType name="NameTextType"> <annotation> <documentation xml:lang="EN">Domain definition for the text of an individual name part.</documentation> </annotation> <simpleContent> <restriction base="shr:BiLingualTextType"> <maxLength value="80"/> </restriction> </simpleContent> </complexType>

simpleType GenderType

source <simpleType name="GenderType"> <annotation> <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> </annotation> <restriction base="string"> <enumeration value="0"/> <enumeration value="1"/> <enumeration value="2"/> <enumeration value="9"/> </restriction> </simpleType>

simpleType IndividualIDType

source <simpleType name="IndividualIDType"> <annotation> <documentation xml:lang="EN">Domain definition for the Individual ID.</documentation>


43

</annotation> <restriction base="pc:PartyIDType"/> </simpleType>

simpleType MaritalStatusType

source <simpleType name="MaritalStatusType"> <annotation> <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> </annotation> <restriction base="string"> <enumeration value="N"/> <enumeration value="M"/> <enumeration value="S"/> <enumeration value="D"/> <enumeration value="W"/> </restriction> </simpleType>

simpleType MilitaryServiceNumType

source <simpleType name="MilitaryServiceNumType"> <annotation> <documentation xml:lang="EN">Domain definition for the Service Number assigned to a member of the Canadian Forces, such as F12 345 678.</documentation> </annotation> <restriction base="string"> <maxLength value="9"/> </restriction> </simpleType>

simpleType NameFormalityType

source <simpleType name="NameFormalityType"> <annotation> <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> </annotation> <restriction base="string"> <enumeration value="Legal"/> <enumeration value="Formal"/> <enumeration value="Informal"/> </restriction> </simpleType>

simpleType NameType

source <simpleType name="NameType"> <annotation> <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> </annotation> <restriction base="string"> <enumeration value="10"/>


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

source <simpleType name="SocialInsuranceNumType"> <annotation> <documentation xml:lang="EN">Domain definition for the Social Insurance Number.</documentation> </annotation> <restriction base="string"> <pattern value="[0-9]{9}"/> </restriction> </simpleType>

3.2.4 GOOrganization

Schema GOOrganization2.0.0.xsd TargetNamespace: GOOrganization2.0.0 Imported Namespace: GOShared2.0.0 GOCommonParty2.0.0

Complex types Simple types

AdminOrganizationUnitType ActivityClassificationType

FederalBusinessIdentificationType BusinessRegistrationNumType

FormalOrganizationType JurisdictionType

InformalOrganizationType OntBusinessEstablishmentType

NameTextType OntBusinessStatusType

OntarioBusinessRegistrationType OrganizationIDType

OrganizationNameType OrganizationStructureType

OrganizationType OrgNameFormalityType

ProgramIdentifierType

ReferenceNumType

RegistrationNumType


45

complexType AdminOrganizationUnitType


46

Diagram


47

Source <complexType name="AdminOrganizationUnitType"> <annotation> <documentation xml:lang="EN">A portion of a Formal Organization dedicated to a specific purpose, such as a department, branch or unit.</documentation> </annotation> <complexContent> <extension base="o:OrganizationType"/> </complexContent> </complexType>

complexType FederalBusinessIdentificationType

diagram

source <complexType name="FederalBusinessIdentificationType" final="#all"> <annotation> <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> </annotation> <sequence> <element name="RegistrationNum" type="o:RegistrationNumType"> <annotation> <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> </annotation> </element> <element name="ProgramID" type="o:ProgramIdentifierType"> <annotation> <documentation xml:lang="EN">A unique identifier of a government program, assigned by the Canada Customs and Revenue Agency.</documentation> </annotation> </element> <element name="ReferenceNum" type="o:ReferenceNumType"> <annotation>


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> </annotation> </element> </sequence> </complexType>


49

complexType FormalOrganizationType


50

diagram


51

source <complexType name="FormalOrganizationType"> <annotation> <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> </annotation> <complexContent> <extension base="o:OrganizationType"> <sequence> <element name="FiscalYearEndMonthDay" type="shr:MonthDay" minOccurs="0"> <annotation> <documentation xml:lang="EN">The month and day when the Organization's fiscal (financial) year ends.</documentation> </annotation> </element> <element name="ActivityClassificationCode" type="o:ActivityClassificationType" minOccurs="0"> <annotation> <documentation xml:lang="EN">A code used to indicate the main activity of the Organization.</documentation> </annotation> </element> <element name="OrganizationTypeCode" type="o:OrganizationStructureType" minOccurs="0"> <annotation> <documentation xml:lang="EN">A code used to indicate the type of an Organization.</documentation> </annotation> </element> <element name="FederalBusinessID" type="o:FederalBusinessIdentificationType" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation xml:lang="EN">An Organization may have zero or many Federal Business Identifications.</documentation> </annotation> </element> <element name="OntBusinessRegistration" type="o:OntarioBusinessRegistrationType" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation xml:lang="EN">An Organization may have zero or many Ontario Business Registrations.</documentation> </annotation> </element> <choice minOccurs="0"> <element name="IncorporatedCountryCode" type="shr:ISO3166-1Alpha2CountryCodeType"> <annotation> <documentation xml:lang="EN">The two-letter ISO 3166-1: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> </annotation> </element> <element name="IncorporatedProvinceStateCode" type="shr:CanadaPostProvinceStateCodeType"> <annotation> <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> </annotation> </element> </choice> </sequence> <attribute name="jurisdictionType" type="o:JurisdictionType" use="optional"> <annotation> <documentation xml:lang="EN">A code used to indicate the type of jurisdiction in which the organization is registered.</documentation> </annotation> </attribute> </extension> </complexContent> </complexType>


52

complexType InformalOrganizationType


53

diagram


54

source <complexType name="InformalOrganizationType"> <annotation> <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> </annotation> <complexContent> <extension base="o:OrganizationType"/> </complexContent> </complexType>

complexType NameTextType

diagram

source <complexType name="NameTextType"> <annotation> <documentation xml:lang="EN">Domain definition for organization name or abbreviation text.</documentation> </annotation> <simpleContent> <restriction base="shr:BiLingualTextType"/> </simpleContent> </complexType>

complexType OntarioBusinessRegistrationType

diagram

source <complexType name="OntarioBusinessRegistrationType" final="#all"> <annotation> <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> </annotation> <sequence> <element name="BusinessRegistrationNum" type="o:BusinessRegistrationNumType"> <annotation> <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> </annotation> </element> <element name="EstablishmentTypeCode" type="o:OntBusinessEstablishmentType" minOccurs="0"> <annotation>


55

<documentation xml:lang="EN">The type of business as registered by ONBIS.</documentation> </annotation> </element> <element name="StatusCode" type="o:OntBusinessStatusType" minOccurs="0"> <annotation> <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> </annotation> </element> </sequence> </complexType>

complexType OrganizationNameType

diagram

source <complexType name="OrganizationNameType"> <annotation> <documentation xml:lang="EN">A name used to identify an Organization for legal or operational purposes.</documentation> </annotation> <sequence> <element ref="o:Name"> <annotation> <documentation xml:lang="EN">The full text of the name or abbreviation used to identify the Organization.</documentation> </annotation> </element> <sequence minOccurs="0"> <element ref="pc:StartDate"> <annotation> <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> </annotation> </element> <element ref="pc:EndDate" minOccurs="0"> <annotation> <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> </annotation> </element> </sequence> </sequence> <attribute name="formality" type="o:OrgNameFormalityType"> <annotation> <documentation xml:lang="EN">A code used to indicate the appropriate usage of the name.</documentation> </annotation> </attribute> </complexType>


56

complexType OrganizationType


57

diagram


58

source <complexType name="OrganizationType"> <annotation> <documentation xml:lang="EN">A group of Individuals that has allocated resources. An Organization must represent itself as a unit, with a leader or a single point of contact. Organizations include legally constituted bodies, informally constituted groups, and the hierarchy of administrative units of an Organization.</documentation> </annotation> <complexContent> <extension base="pc:PartyType"> <sequence> <element ref="o:Name" minOccurs="0"> <annotation> <documentation xml:lang="EN">The full text of the name or abbreviation used to identify the Organization.</documentation> </annotation> </element> <element name="ActivityDesc" type="shr:DescriptionTextType" minOccurs="0"> <annotation> <documentation xml:lang="EN">A narrative description of a business endeavour or other organizational activity. This may include products sold, services provided or machinery or equipment used.</documentation> </annotation> </element> <sequence minOccurs="0"> <element ref="pc:StartDate"> <annotation> <documentation xml:lang="EN">The date when the Organization was created, incorporated or began operations.</documentation> <appinfo>Data Integrity Rule: 1. IF EndDate of OrganizationType is used THEN StartDate of OrganizationType must also be used.</appinfo> </annotation> </element> <element ref="pc:EndDate" minOccurs="0"> <annotation> <documentation xml:lang="EN">The date when the Organization was dissolved, or ceased operations.</documentation> <appinfo>Data Integrity Rule: 1. IF EndDate of OrganizationType has a value THEN EndDate of OrganizationType must be >= StartDate of OrganizationType.</appinfo> </annotation> </element> </sequence> <element name="OrganizationName" type="o:OrganizationNameType" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation xml:lang="EN">An Organization may have zero, one or many alternative names.</documentation> </annotation> </element> </sequence> </extension> </complexContent> </complexType>

simpleType ActivityClassificationType

source <simpleType name="ActivityClassificationType"> <annotation> <documentation xml:lang="EN">Domain definition for the activity code in describing the industry or other main activity of the Organization, based on the most recent industrial classification codes from Statistics Canada (currently NAICS 2002 six-digit codes).</documentation> </annotation> <restriction base="string"> <maxLength value="6"/> </restriction> </simpleType>

simpleType BusinessRegistrationNumType

source <simpleType name="BusinessRegistrationNumType"> <annotation>


59

<documentation xml:lang="EN">Domain definition for the identifier of the business in the ONBIS system. Also known as the Establishment Identification Number.</documentation> </annotation> <restriction base="string"> <maxLength value="11"/> <pattern value="[A-C][A-Z,0-9]{7,9}"/> </restriction> </simpleType>

simpleType JurisdictionType

source <simpleType name="JurisdictionType"> <annotation> <documentation xml:lang="EN">Domain definition for the code to indicate the type of jurisdiction in which the organization is registered.</documentation> <appinfo>The recommended Jurisdiction codes are: Federal - Federal level jurisdiction, and Provincial - Provincial, territorial, or state level jurisdiction.</appinfo> </annotation> <restriction base="string"> <enumeration value="Federal"/> <enumeration value="Provincial"/> </restriction> </simpleType>

simpleType OntBusinessEstablishmentType

source <simpleType name="OntBusinessEstablishmentType"> <annotation> <documentation xml:lang="EN">Domain definition for the types of business registered by ONBIS.</documentation> <appinfo>Ontario Business type codes are available in the CDER table ONT_BUSINESS_TYPE. Valid values are: A - Ontario Business Corp, B - Ontario Corp non-share, C - Credit Union, D - Insurer, F - Social Club with share, G - Social Club non-share, H - Cooperative non-share, J - Cooperative with share, K - Extra-Provincial Foreign with share, M - Condominium Corporation, P - Loan and Trust Corp, R - Federal Corp with share, S - Federal Corp non-share, T - Extra-Provincial Foreign Insurer, U - Extra-Provincial Foreign non-share, W - Agencies, Boards, Commissions, X - Extra-Provincial Domestic non-share, Y - Extra-Provincial Domestic with share, Z - Non-filers (exempt from filing under CIA), SP - Sole Proprietorship, GP - General Partnership, LP - Limited Partnership, OP - Ontario Limited Liability Part, CO - Extra-Provincial Limited Liability Co., EP - Extra-Provincial Limited Liability Part, AN - Business Name - Corp., PN - Partnership Business Name, and L - Pending file (either corporation or small business).</appinfo> </annotation> <restriction base="string"> <enumeration value="A"/> <enumeration value="AN"/> <enumeration value="B"/> <enumeration value="C"/> <enumeration value="CO"/> <enumeration value="D"/> <enumeration value="EP"/> <enumeration value="F"/> <enumeration value="G"/> <enumeration value="GP"/> <enumeration value="H"/> <enumeration value="J"/> <enumeration value="K"/> <enumeration value="L"/> <enumeration value="LP"/> <enumeration value="M"/> <enumeration value="OP"/> <enumeration value="P"/> <enumeration value="PN"/> <enumeration value="R"/> <enumeration value="S"/> <enumeration value="SP"/> <enumeration value="T"/> <enumeration value="U"/> <enumeration value="W"/> <enumeration value="X"/>


60

<enumeration value="Y"/> <enumeration value="Z"/> </restriction> </simpleType>

simpleType OntBusinessStatusType

source <simpleType name="OntBusinessStatusType"> <annotation> <documentation xml:lang="EN">Domain definition for the status of the business registration in ONBIS.</documentation> <appinfo>Ontario Business Status type codes are available in the CDER table ONT_CORP_STATUS. Valid values are: 0 - active, 1 - cancellation process - O.S.C. (Ontario Securities Commission), 2 - cancellation process - C.T. (Corporations Tax, MOF), 3 - cancellation process - C.B. (Companies Branch), 4 - information notice sent, 6 - bankruptcy (proposal), 7 - continued in Ontario, A - cancelled by O.S.C., B - cancelled by C.T., C - cancelled by C.B., D - voluntary dissolution, E - ceased in Ontario (E.P. corp), F - amalgamation, G - ceased in Ontario (federal corp), H - dissolving co-operative, K - cancellation for cause, N - termination (condiminium), P - ceased in Ontario (E.P. insurer), V - voluntary winding up, W - dissolving credit unions, X - final removal (all E.P. corps), I - Inactive, T - Cancelled for Cause, L - Deletion, J - Dissolution, and Z - Withdrawal.</appinfo> </annotation> <restriction base="string"> <enumeration value="0"/> <enumeration value="1"/> <enumeration value="2"/> <enumeration value="3"/> <enumeration value="4"/> <enumeration value="6"/> <enumeration value="7"/> <enumeration value="A"/> <enumeration value="B"/> <enumeration value="C"/> <enumeration value="D"/> <enumeration value="E"/> <enumeration value="F"/> <enumeration value="G"/> <enumeration value="H"/> <enumeration value="I"/> <enumeration value="J"/> <enumeration value="K"/> <enumeration value="L"/> <enumeration value="N"/> <enumeration value="P"/> <enumeration value="T"/> <enumeration value="V"/> <enumeration value="W"/> <enumeration value="X"/> <enumeration value="Z"/> </restriction> </simpleType>

simpleType OrganizationIDType

source <simpleType name="OrganizationIDType"> <annotation> <documentation xml:lang="EN">Domain definition for the Organization ID.</documentation> </annotation> <restriction base="pc:PartyIDType"/> </simpleType>

simpleType OrganizationStructureType

source <simpleType name="OrganizationStructureType"> <annotation> <documentation xml:lang="EN">Domain definition for the legal structure of the organization.</documentation> <appinfo>The Organization Type Codes are available in the CDER table ORGANIZATION_TYPE. Current valid codes are: 01 - Sole Proprietorship, 02 - Partnership, 03 - Corporation, 98 - Unknown, and


61

99 - Other. Codes may be added in the range 04 to 97 for purposes of specific programs and services.</appinfo> </annotation> <restriction base="string"> <enumeration value="01"/> <enumeration value="02"/> <enumeration value="03"/> <enumeration value="98"/> <enumeration value="99"/> </restriction> </simpleType>

simpleType OrgNameFormalityType

source <simpleType name="OrgNameFormalityType"> <annotation> <documentation xml:lang="EN">Domain definition for the formality of organization name.</documentation> <appinfo>The recommended Organization Formality Type codes can be found in the CDER table NAME_FORMALITY. These codes include: L - Legal (as registered in ONBIS), O - Operating (as registered in ONBIS. Synonyms: Trade Name, Style Name, Business Name, Operating Under), S - Statute or Regulation (established in legislation), C - Common (used but not registered with MCBS), and A - Abbreviation or Acronym</appinfo> </annotation> <restriction base="string"> <enumeration value="Abbreviated"/> <enumeration value="Common"/> <enumeration value="Legal"/> <enumeration value="Operation"/> <enumeration value="Statute"/> </restriction> </simpleType>

simpleType ProgramIdentifierType

source <simpleType name="ProgramIdentifierType"> <annotation> <documentation xml:lang="EN">Domain definition for an unique federal government program identifier.</documentation> </annotation> <restriction base="string"> <length value="2"/> </restriction> </simpleType>

simpleType ReferenceNumType

source <simpleType name="ReferenceNumType"> <annotation> <documentation xml:lang="EN">Domain definition for an unique identifier of one operating entity, designated by the Federal Business Number registrant to undertake program-specific dealings with the Government on the registrant's behalf.</documentation> </annotation> <restriction base="string"> <pattern value="[0-9]{4}"/> </restriction> </simpleType>

simpleType RegistrationNumType

source <simpleType name="RegistrationNumType"> <annotation> <documentation xml:lang="EN">Domain definition for an unique identifier of a private or public sector entity, assigned by the Canada Customs and Revenue Agency.</documentation> </annotation> <restriction base="string"> <pattern value="[0-9]{9}"/>


62

</restriction> </simpleType>

4 Usage Rules

4.1 General GOCDES Usage Rules

1. OPS XML Schemas (OPSS) that utilize concepts defined in CDES must use GOCDES XML

Schema components. The use of GOCDES components in OPSS is essential for standardizing and sharing common data element specifications across all OPS applications, and particularly, across shared transactional message schemas.

2. Use of the XML Schema element is recommended when both an element and a type (simple

or complex) are defined for the same concept in GOCDES. Use of the element not only guarantees the standardization of the data type structure, but also achieves the standardization of names.

3. An OPSS may introduce new elements that make reference to the GOCDES components

when a. The OPSS uses multiple references to the same GOCDES component. b. The name of an OPSS element needs to express the application specific business

meaning of the GOCDES component being referenced.

4. If an OPS application requires extension or redefinition of a GOCDES element or type, the following options should be considered (in the order of preferences as indicated):

a. Extend a GOCDES type. b. Extend a component that is referenced from a GOCDES subtype. c. Introduce a new schema element or type (simple type or complex type) by making

reference to the existing GOCDES components. d. Add, remove or change data integrity rules. e. Redefine a GOCDES schema element or type. f. Introduce a new component that does not make reference to any existing GOCDES

component.

The above changes can be done only if a XML Schema component allows extension (indicated in its specification). The new schema components should be defined within an OPSS namespace that contains only OPSS extensions to GOCDES components.

5. Should an OPS application opt to use a JAXB tool that does not support some constructs of

the W3C XML Schema specification then GOCDES 2.0 components may be modified to meet the restrictions of the selected JAXB tool. However, these modifications will be justified only if the semantics of the changed GOCDES components remains the same.


63

4.2 GOCDES 2.0.0 Party and Party Contact Schema Usage Rules

1. Mandatory Use of CDES Party and Party Contact components. One or more of the

following components of the CDES Party and Party Contact Schemas must be used in OPS cluster or ministry common schemas, project schemas, application schemas, or transactional schemas (OPSS) that require party elements:

A. Party

B. Individual

C. Organization

D. Contact List

2. Using selected CDES Party namespaces. If OPSS does not use all namespaces of Party (Organization, Individual, Party Common), it can reference only selected CDES namespaces. For example, if the namespace Individual is not required, OPSS can reference only the namespaces Organization and Party Common.

3. Extensions of Organization and Individual. Subtypes Organization and Individual, or their CDES subtypes, can be extended to one or many OPSS specific subtypes, if these subtypes are not already defined in the CDES. These subtypes will be defined in a project-specific name space, according to CDES general usage rule 2 [Related Document 3]. For example, complex types Ministry, Ministry Cluster, Ministry Department, etc. can be introduced as extensions of complex type Formal Organization.

4. Specification of Roles. Roles can be restricted to specific project roles. For example, the Service Party Role, which is a restriction of type Party Role, may enumerate role codes used in Service XML schemas.

5. Extensions of Party Role. Party Role can be extended if it requires new specific attributes or specific context name. For example, party roles related to service delivery can be modeled as Service Party Role, which is a subtype of CDES Party Role and has the attribute Service, as shown in Figure 9.

Role

<<elt>> Code [0..1] : RoleCodeType

<<elt>> Name : RoleNameType

<<elt>> Desc [0..1] : RoleDescType

<<complexType>>

Party


<<elt>> PreferredOfficialLanguageCode [0..1] : OntOfficialLanguageType

<<elt>> PreferredLanguageCode [0..1] : LanguageType

<<att>> FirstNationsStatusFlag [0..1] : FlagType

<<complexType>>

Party Role



<<complexType>>

10..* 1

+Role

0..*

1

1..*

+Party 1

+PartyRole

Service

<<complexType>>

ServicePartyRole

<<complexType>>

10..*

+Service

1

+ServicePartyRole

0..*

Introduce Party Role

Extensions with specific

Party Role Attributes in

OPS application namespaces

<<extends>>

Role




<<complexType>>

Party


<<elt>> PreferredOfficialLanguageCode [0..1] : OntOfficialLanguageType



<<complexType>>

Party Role



<<complexType>>

10..* 1

+Role

0..*

1

1..*

+Party 1

+PartyRole

Service

<<complexType>>

ServicePartyRole

<<complexType>>

10..*

+Service

1

+ServicePartyRole

0..*


Extensions with specific

Party Role Attributes in

OPS application namespaces

<<extends>>

Figure 9 Extension of Party Role


64

6. Extensions of Party Role Relationship. Party Role Relationship can be extended if it requires additional attributes or presents an N-nary association. For example, Figure 10 shows relation for representation (Party A represents Party B at Party C then their association requires three party roles instead of two: RepresentingParty (A), RepresentedByParty (B), RepresentedAtParty (C). In this case the RepresentingParty is the subject of the relationship Representation, RepresentedByParty is the object of the relationship and RepresentedAtParty is the predicative object of the relationship. To model this case, two new subtype classes are introduced: Representation as the subtype class of Party Role Relationship and Representation Party Role as the subtype class of Party Role. This pattern can be extended to model general N-nary relationship between parties.


and Party Role

Relationship

Extensions in OPS

application namespace


<<elt>> RelationshipCode : PartyRelationshipType

<<elt>> StartDate : Date


<<complexType>>

Role




<<complexType>>

Party


<<elt>> PreferredOfficialLanguageCode [0..1] : OntOfficialLanguageType...



<<complexType>>

Party Role



<<complexType>>1

+SubjectRole

1

+SubjectRoleRelationship

0..*

1 0..*

+ObjectRole

1

+ObjectRoleRelationship

0..*

1

0..*

1

+Role

0..*

1 +Party

+PartyRole 1..*

Representation

<<complexType>>Represenation Party Role

<<complexType>>1..*

1 +PredicativeRoleRelationship

1..*+PredicativeRole

1

<<extends>> <<extends>>


and Party Role

Relationship

Extensions in OPS

application namespace


<<elt>> RelationshipCode : PartyRelationshipType

<<elt>> StartDate : Date


<<complexType>>

Role




<<complexType>>

Party


<<elt>> PreferredOfficialLanguageCode [0..1] : OntOfficialLanguageType...



<<complexType>>

Party Role



<<complexType>>1

+SubjectRole

1

+SubjectRoleRelationship

0..*

1 0..*

+ObjectRole

1

+ObjectRoleRelationship

0..*

1

0..*

1

+Role

0..*

1 +Party

+PartyRole 1..*

Representation

<<complexType>>Represenation Party Role

<<complexType>>1..*

1 +PredicativeRoleRelationship

1..*+PredicativeRole

1

<<extends>> <<extends>>

Figure 10 Example of N-ary Relationships between Parties


65

Errata GO-ITS Standard No. 27.0, Version 1.4

Created: Original version of GOCDES, version 1.7d, was created on March 12, 2003. Resulting GO-ITS 27 approved by ITSC on April 15, 2003

GO-ITS Standard No. 27.1, Version 2.0

Revised: Created updated version of GOCDES as version 2.0 on March 9, 2004. See GOCDES 2.0 Change Record in Appendix A for change details.

Approved: March 17, 2004

Approved by the IT Standards Council as a revised Government of Ontario Information Technology Standard (GO-ITS)

GO-ITS Standard No. 27.2, Version 2.0.0 Created: Created updated version of GOCDES as version 2.0.0 on Feb 8, 2005

Approved: March 16, 2005 Approved by the IT Standards Council as a revised Government of

Ontario Information Technology Standard (GO-ITS)


66

Document Numbering Document No: GO-ITS 27.2 Title: Information Standard for Party and Party Contact Specification using Government

of Ontario CDE XML Schema (GOCDES) File Name: GO-ITS 27.2 IT Standard Version 2.0.0


68

Appendix A: Additional Information

Abbreviations and Acronyms CDE Common Data Elements CDEM BVLDM Common Data Elements Model, Business View Logical Data

Model CDES Common Data Elements XML Schema CDES LDM CDE XML Schema Logical Data Model ERM Entity Relationship Model ERD Entity Relationship Diagram GO Government of Ontario GOCDES GO CDE XML Schemas Physical Data Model and Source

Code GOCDES Component XML Schema element or type defined in the GOCDE XML

Schema GOCDES DOC GO CDE XML Schema Documentation GOCDES PDM GO CDE XML Schema Physical Data Model GOCDES SC GO CDE XML Schema Source Code JAXB Java API for XML Binding LDM Logical Data Model OPS Ontario Public Service OPS IMH OPS Information Modeling Handbook OPSS Transactional, document , common cluster or common ministry XML

Schema that uses GOCDES components PDM Physical Data Model (Graphical Presentation of XML

Schemas) UML Unified Modeling Language


69

Change Control

Technical Standards Change Control Process

Once a technical standard has received final approval, there immediately becomes a requirement for maintaining its relevance and currency. Once approved, all standards undergo an annual review process, whereby the Technical Coordinator

2 will determine if it needs to be updated in any

way. The Technical Coordinator may contact the originating body as needed to contribute to this decision process. New standards development may also require a detailed review process during the first year after they have been approved, so the standard can be further refined through an iterative process. The following process describes the procedure and documentation required to accomplish this task.

Change Control Procedure

1. Identify need to modify the standard. 2. Request a change to the standard by sending an email to the Standards Coordinator or

request a meeting to discuss the required change. The request for change should include the information outlined in the TODO column of the change control spreadsheet (either include this information in the email or attach a filled out copy of the TODO column).

3. The Standards Coordinator will review the request and determine if the request can be

accepted as is or if more information is required. The Standards Coordinator will try and resolve any issues with the lead group and set up meetings with the domain working group(s) if required.

4. The Standards Coordinator finalizes the revision request including the resolutions

recommended by the appropriate lead group/working group personnel.

5. The Standards Coordinator records the modifications required to the standard in the TODO column of the change control spreadsheet.

6. When significant changes have been requested, or every three months, which ever comes

first, the spreadsheet will be reviewed by the ITSC for approval/decline of requested changes.

7. After final review by the ITSC, and upon approval of the Technical Standards Manager,

the spreadsheet is implemented by the Technical Coordinator for implementation by a requested date.

8. The Technical Coordinator updates the standard, and updates the TODO column in the

change control spreadsheet with the revision date and informs (via email) the standards section staff and all ITSC members, that the changes in the attached spreadsheet have been completed. The revised standard is posted on the ITSC intranet site.

2 Note that for change control of XML code such as CDE schema, the role of Technical

Coordinator is performed by the corporate XML specialist in the Information & Business Architecture Section and can be reached by phone at 416-212-4436.


70

9. The updated standard then goes to ARB for final approval. ARB will cancel or approve the

process. If approved, the revised standard is posted on the GO-ITS public web site. The Technical Coordinator then moves the requested changes to the DONE column of the change control spreadsheet.

Note: This process is followed for significant (definitive) technical standards during their first year when it is expected that they will undergo refinement. It is not routinely applied every year to every standard. It may be applied to an existing standard, if during the annual review by the Technical Coordinator, it is determined that the standard requires significant revision/replacement.

Change Control Documentation

This procedure requires that the Standards Coordinator maintain a spreadsheet. A spreadsheet that logs:

• all pending changes in the TODO column • all completed changes in the DONE column

The columns on the spreadsheet (e.g. Technical Standards Change Request) represent the following information:


71

Table 1: Technical Standards Change Request

Change Request Column Description

ID A sequential number assigned to track change requests

Standard Name and GO-ITS number Name of the standard affected by the change

Change Description Type of change being requested

Request Date Date the change request was submitted

Requested By Name of the person submitting the change request

Request Description Justification for the requested change

Date Updated/or Date of Decision to Decline Change Request

Date that the change was implemented in the standard, or if not, the date the decision was made not to implement the change

If Declined: Justification Justification for the requested change to be declined, if applicable

Completed by Name of the person that completed the change request


72

GOCDES 2.0.0 Change Record

1. Implemented all changes elaborated in the CDEM BVLDM. Please see the corresponding

BVLDM Party 2.0.0 documentation. 2. Specified Data Integrity Rules in the application information section of the XML Schema

annotations. These rules should be implemented in the OPS applications that utilize GOCDES 2.0 XML Schemas.

3. Applied Data Integrity Rules to control consistent use of French or English codes for

address elements in each XML Instance.

4. Removed attributes for hints, helps and prompts.

5. Removed XML Schema “building blocks”. The building blocks in GOCDES 1.7d presented a redundant specification of CDES party concepts in the form of composition rather than generalization.


73

Known Issues N/A


74

List of Related Documents

1. Common Data Elements Model, Party Subject Area, Business View Logical Data Model, Version 2.0.0, Corporate Architecture and Standards Branch, Ontario Government Management Board Secretariat, May 2004, http://intra.eia.cio.gov.on.ca/mbs/eia/frame00.nsf/Items/50E8DA2430BC343985256D2D006847B5?opendocument

2. Common Data Elements Model, Addressing Subject Area, Business View Logical Data Model,

Version 2.0.0, Supplementary Documentation, Corporate Architecture and Standards Branch, Ontario Government Management Board Secretariat, November 2003, http://intra.eia.cio.gov.on.ca/mbs/eia/frame00.nsf/Items/50E8DA2430BC343985256D2D006847B5?opendocument

3. XML Common Data Elements Schema, Logical Data Model for XML Schema Design, Version

1.0.0, Corporate Architecture and Standards Branch, Ontario Government Management Board Secretariat, January 2005,

4. Information Standard for Address Specification using Government of Ontario CDE Schema,

GO-ITS Standard Document No. 27, Version 1.4, April, 2003, http://www.gov.on.ca/MBS/techstan/GO_ITS_27.pdf

5. Information Standard for Address Specification using Government of Ontario CDE Schema,

GO-ITS Standard Document No. 27.1, Version 2.0, March, 2004, http://www.gov.on.ca/MBS/techstan/GO_ITS_27.pdf

6. Common Data Elements XML Schema Address Subject Area Logical Data Model and

Schema Design, Version 2.0.0, Corporate Architecture and Standards Branch, Ontario Government Management Board Secretariat, May 2004, http://intra.eia.cio.gov.on.ca/mbs/eia/frame00.nsf/Items/50E8DA2430BC343985256D2D006847B5?opendocument

7. Government of Ontario CDES Party and Party Contact Schema, Version 2.0.0, Corporate

Architecture and Standards Branch, Ontario Government Management Board Secretariat, Feburary 2005.

8. Government of Ontario CDES Party and Party Contact Schema XML Sample Instances,

Corporate Architecture and Standards Branch, Ontario Government Management Board Secretariat, Feburary 2005.


75

References

1. OPS Information Modeling Handbook, Version 3.0, Corporate Architecture and Standards Branch, Ontario Government Management Board Secretariat, June 2003, http://intra.eia.cio.gov.on.ca/mbs/eia/frame00.nsf/Items/50E8DA2430BC343985256D2D006847B5?opendocument

2. OASIS CIQ International Standards (xAL, xNL, xNAL, xCIL, etc.), Version 2.0,

http://www.oasis-open.org/committees/ciq/ciq.html 3. W3C XML Schema Standard Recommendation Version 1.0,

http://www.w3.org/TR/xmlschema-1/ 4. XML Schemas: Best Practices, Tutorial on XML Schemas, xFront, February 17, 2003,

http://www.xfront.com/BestPracticesHomepage.html 5. UML and XML Schema, a research paper by Nicholas Routledge, Linda Bird and Andrew

Goodchild, published by Australian Computer Society, Inc., 2001. Also appeared at the Thirteenth Australasian Database Conference (ADC2002), http://titanium.dstc.edu.au/papers/adc2002.pdf

6. Modeling XML Applications with UML, David Carlson, Addison-Wesley, 2001.