# Presentation: 066116

## WIJIS Messaging Model

- G. W. Pasdirtz, Ph.D., WIJIS
- Joe Mierwa, Visionair

**Notes:**
WIJIS is the Wisconsin Integrated Justice Information Sharing project. Visionair provides an Web Service-enabled RMS system for one of the WIJIS pilot sites in La Crosse County. We plan to communicate using a GJXDM message model.

## Agenda

- High Level Overview
- Associations
- Current mechanisms
- Proposed Solutions
- A WIJIS solution
- GJXDM Object-Relational Mapping Issues
- Object Inclusion vs. Object Separation
- Object Reference
- Aggregation vs. Composition
- Associations

**Notes:**
Based on the needs of the WIJIS messaging model, we will advance yet another proposal for serializing objects using the GJXDM. The proposal eliminates the impedance mismatch between using XML for document tagging (XML-DOC) and using XML for loading relational databases (XML-DB). The issues become clear by stepping through an object-relational mapping exercise in which an XML schema is mapped to an object schema (UML diagram) and finally to a database schema (SQL DDL). The major problem encountered involves how associations between objects are mapped.

## The Context

## WIJIS Federated SOA

**Notes:**
The WIJIS Federated Service Oriented Architecture (SOA) includes Law Enforcement, DOJ, DA, Corrections and Others (DOT, DHS, etc.). 

Each Class A Partner is assumed to have a portal, LDAP-compliant directory and lots of data. 
The Enterprise Services Bus (ESB) provides services that facilitate the SOA, to include message transformation (to GJXDM) and workflow. 
The WIJIS index is another Web Service that provides an index to activity within the Wisconsin Criminal Justice System and sophisticated search functionality. 

Our goal is a plug-and-play environment in which systems can interact using a standardized GJXDM messaging model. 

The system scales easily as new services (WS-enabled systems) are added. Since there is no single point of failure, the system is robust with respect to changes in services. The system can also evolve over time, for example, if better search software is developed, the legacy functionality can be unplugged and replaced with a better Web Service without disrupting the system, provided there are no interface changes. 

The system is also sustainable in that partner systems can participate without relying on central funding.

## Workflow

**Notes:**
Here’s how it’s supposed to work:
 Law Enforcement (or some other agency) publishes activity to the ESB
 The ESB checks other partners for related information (Finger Prints, Mug Shots, Criminal Histories, Hot Files, etc.) and gathers URLs to the documents found. The ESB forms shallow objects, to include URLs, and forwards to the WIJSI index using XML-DB.
 Law Enforcement (or other agencies) can query or subscribe to the index using XML-RPC.

## The WIJIS Index

- Relies on a Publish/Subscribe model
- Does NOT extract data from ODSs or Data Warehouses
- Is NOT a data mart
- It is a pointer system optimized for searching

**Notes:**
The WIJIS index relies on a publish/subscribe model. It does not extract data from ODSs or Data Warehouses. It is not a Data Mart. It is a pointer system optimized for searching.

## GJXDM & NIEM

**            **

**NIEM 1.0**

**Homeland****Security**

**Other**

**Justice**

**GJXDM 3.X**

**Core**

**U-Core**

**Notes:**
The data shared with WIJIS uses the GJXDM. As the evolution of the National Information Exchange Model (NIEM) concept continues, the GJXDM is expected to metamorphose into. 

The NIEM divides GJXDM into three categories: 
 “Universal Core data types” have applicability across all information domains. 
 “Core Data Types” have applicability across two or more, but not all information domains. And 
 Individual domains can reuse and extend these core data types to meet domain-specific needs.

## GJXDM Shallow Objects

**Notes:**
The GJXDM object structure is based on inheritance. The “core” objects inherit attributes from the super object. The object structure makes it easy to define shallow objects, that is,  identify key fields for person, property, location, organization, document contact information and activity objects. It would also seem easy to load the objects as tables in a database. However, GJXDM Associations are not modeled as a separate object but rather modeled as attributes of the core objects, creating potential problems for indexing, referential integrity and normalization when using XML-DB. 

From the NIEM standpoint, associations are either “universal core” or “domain specific”. The NIEM concept suggest that we look carefully at XML-DOC descriptions first as a collection of objects. That is,  (1) view the document as a collection of objects divided into “core,” “universal core,” and “domain specific” types and (2) pay special attention to the modeling and consistent definition of core types.

## Multiple Message Models

- XML-DOC: incident, arrest, citation, etc.
- XML-RPC: query
- XML-DB: publish to the WIJS index
- Flat File: SOA Class C Systems

**Notes:**
XML is a flexible data modeling language that can be used for describing documents (XML-DOC), remote procedure calls (XML-RPC) and database structures (XML-DB). GJXDM is targeted at XML-DOC applications. GJXDM could also be used for XML-DB applications, such as indexing. However, there is a mismatch in the way GJXDM handles associations and the way associations might be handled in a Relational Database (RDB). 

GJXDM-DOC applications also do not easily transform into other file types, such as flat files. XML-DOC can be easily transformed into flat files allowing a migration path for systems that cannot currently generate GJXDM.

## Object-Relational Mapping

**XML Schema**
**(XSD)**

**Object Schema**
**(UML)**

**RDB Schema**
**(SQL)**

**XML Data Binding**

**Object-Relational**
**Mapping**

**Notes:**
Loading XML into an RDB can involve two steps: 

 XML Data Binding (mapping an XML Schema or DTD to an Object Schema or UML Diagram), 
 Object-Relational Mapping (Mapping an Object Schema to an RDB Schema using SQL DDL). Mapping to the intermediate object schema can be skipped but it usually helps to clarify the modeling and reveal referential integrity and normalization problems.

## The Problem

## Problem Statement

- Existing GJXDM mechanisms are too simplistic to reflect information kept in the Index
- Don’t handle reflexive relationships very well
- Don’t translate very well from objects into database entries

**Notes:**
Reflexive relationships are those where the associated entities can be considered to be peers of one another. An example would be a spousal relationship between Bob & Mary. While in ordinary language, we would say that Bob has a wife named Mary, it is more semantically correct to state the relationship as A spousal relationship exists between Bob & Mary. Mary’s identity is not “contained” within John’s. 

In addition, the primary goal of the GJXDM is to facilitate horizontal & vertical integration. In order for this to be accomplished, the data being integrated is still required to be mapped from database schemas into the GJXDM and vice versa. The current implementation of GJXDM does not cleanly facilitate the necessary mapping for complex relationships, which, is specifically what the IJIS index is required to do. 

## Existing Mechanism #1

- XML-DOC Object Inclusion
- Also referred to as hierarchical inclusion

**ActivityWitness**

**WitnessAccountDescriptionText**

**PersonName**

**PersonName**

**ActivityOfficial.Enforcement**

**Same-As**

**ActivityOfficial.Enforcement**

**Notes:**
UML diagramming by Georgia Tech has revealed some problems with GJXDM, particularly in the way it handles associations. For example, when an enforcement official is also a witness, two instances of the same object must be created when using the GJXDM WitnessType and the EnforcementOfficial Type even though we are referring to the same person. (referred to as a same-as relationship). From the RDB perspective, this type of modeling calls out for normalization.

## Example: Object Inclusion Instance 

**<WIJIS ****	****namespace stuff goes here **
**	****xsi:schemaLocation="http://schemapathdefinition/WijisIndex.xsd">**
**	****<Activity j:id="ActID1">**
**	****	****<ActivityID>4-00-09796-0399-181</jdd:ActivityID>**
**	****	****<ActivityDate>2000-08-23</jdd:ActivityDate>**
**	****	****<ActivityEndDate>14:31:00</jdd:ActivityEndDate>**
**	****	****<ActivityOfficial.Enforcement ID=“****PID1****”>**
**	****	****	****<PersonName><PersonFullName>Bob</PersonFullName></PersonName>**
**	****	****	****<EnforcementOfficialTypeText>some text </EnforcementOfficialTypeText>**
**	****	****	****<EnforcementOfficialBadgeID>**
**	****	****	****	****<ID>1234</ID>**
**	****	****	****<EnforcenmentOfficialBadgeID>**
**	****	****	****<EnforcementOfficialUnit  ID="OID1" >**
**	****	****	****	****<OrganizationID><ID>1234</ID></OrganizationID>**
**	****	****	****	****<OrganizationName>NameText</OrganizationName>**
**	****	****	****</EnforcementOfficialUnit>**
**	****	****</ActivityOfficialEnforcement**
**	****	****<j:ActivityWitness ID=“****PID1****”>**
**	****	****	****<PersonName><PersonFullName>Bob</PersonFullName></PersonName>**
**	****	****	****<WitnessID></WitnessID>**
**	****	****	****<WitnessAccountDescriptionText></WitnessAccountDescriptionText>**
**	****	****	****<WitnessDate></WitnessDate>**
**	****	****</j:ActivityWitness>**
**	****</Activity>**
**</WIJIS>**

**Objects are included**
**within the Activity. ID value indicates they are the same person.**

**Notes:**
To make the problem clearer, here’s the associated XML instance. This XML-DOC approach is called object inclusion because the core objects (the person object in this case) is included in the document whenever it is needed. An RDB, on the other hand, would have only one instance of the person object. The object-relational mapping problem is “What to do when the same included core objects have different data?”

## Existing Mechanism #2

- Use of references
- Also referred to as Aggregation

**Notes:**
Returning to UML again to model the person object, GJXDM uses both aggregation (the hollow diamond) and composition (the filled diamond).

Aggregated parts of a whole are intended to be shared with other objects yet also stand on their own. For example, the US is aggregated from the States. If the US object was removed from the system, Wisconsin could still stand on its own. However, aggregation makes less sense in the GJXDM person object since if the person was removed from the system, the aggregated PersonAccompliceWithSubject should still survive on its own. However, without an associated person reference, the PersonAccompliceWithSubject is meaningless. In database terms, referential integrity would be lost.

## Example: References Instance

**Example: References Instance**

**<WIJIS ****	****namespace stuff goes here **
**	****xsi:schemaLocation="http://schemapathdefinition/WijisIndex.xsd">**
**	****<Activity j:id="ActID1">**
**	****	****<ActivityID>4-00-09796-0399-181</jdd:ActivityID>**
**	****	****<ActivityDate>2000-08-23</jdd:ActivityDate>**
**	****	****<ActivityEndDate>14:31:00</jdd:ActivityEndDate>**
**	****	****<ActivityOfficialReference.Enforcement ref=“****PID1****”/>**
**	****	****<j:ActivityWitnessReference ref=“****PID2****” />**
**	****</Activity>**
**	****<EnforcementOfficial ID=“****PID1****”>**
**	****	****	****<PersonName><PersonFullName>Bob</PersonFullName></PersonName>**
**	****	****	****<EnforcementOfficialTypeText>some text </EnforcementOfficialTypeText>**
**	****	****	****<EnforcementOfficialBadgeID><ID>1234</ID></EnforcenmentOfficialBadgeID>**
**	****	****	****<EnforcementOfficialUnit  ID="OID1" >**
**	****	****	****	****<OrganizationID><ID>1234</ID></OrganizationID>**
**	****	****	****</EnforcementOfficialUnit>**
**	****</EnforcementOfficial>**
**	****<j:Witness ID=“****PID2****”>**
**	****	****	****<PersonName><PersonFullName>Bob</PersonFullName></PersonName>**
**	****	****	****<WitnessID></WitnessID>**
**	****	****	****<WitnessAccountDescriptionText></WitnessAccountDescriptionText>**
**	****	****	****<WitnessDate></WitnessDate>**
**	****</j:Witness>**
**</WIJIS>**

**Objects are referenced**
**from the Activity. **

## Proposed Solutions

## Object Separation

- Role.Of (Georgia Tech)
- XML-DB
- Single Association Table (NDEx)

**Notes:**
For XML-DB uses of GJXDM, it would be useful to have alternatives that allowed object-separation. Under object-separation, referential integrity and normalization would be maintained since only one instance of a particular object would be sent with each XML file.

The three current recommendations for extending the GJXDM to allow object separation are to add 
 a Role.Of attribute (proposed by Georgia Tech), 
 a single association table (proposed by NDEx)
 multiple association tables (proposed by WIJIS).

## Role.Of UML

**Notes:**
In the Georgia Tech proposal, the roles of witness and enforcement official would be aggregated from the person type yet still be a composite of the SuperType. That is, if WitnessType and EnforcementOfficialType are eliminated, the PersonType still remains and can inherit attributes from the SuperType.

## Role.Of Data Graph

**Role.Of Data Graph**

**ActivityWitness**

**WitnessAccountDescriptionText**

**PersonName**

**ActivityOfficial.Enforcement**

**Role-Of**

**ActivityOfficial.Enforcement**

**Role-Of**

**Notes:**
In this example data graph of the Role.Of solution, an activity is still associated with witness “Bob1” and law enforcement official “Bob2,” but now each only references one “Bob” through the PersonType “Bob3”.

Notice that the Role.Of solution is essentially modeling an association between a person and an activity. In this case, Bob is associated with an activity both as witness and enforcement official.

## Role.Of Instance

**<WIJIS ****	****namespace stuff goes here **
**	****xsi:schemaLocation="http://schemapathdefinition/WijisIndex.xsd">**
**	****<j:Activity> **
**	****	****<j:ActivityWitness j:id="****b1****"> **
**	****	****	****<j:RoleOf.Person j:id="****p1****"> **
**	****	****	****	****<j:PersonName> **
**	****	****	****	****	****<j:PersonGivenName>Bob</j:PersonGivenName>**
**	****	****	****	****</j:PersonName> **
**	****	****	****</j:RoleOf.Person>**
**	****	****	****<j:WitnessAccountDescriptionText>**
**	****	****	****	****I saw the whole thing**
**	****	****	****</j:WitnessAccountDescriptionText> **
**	****	****</j:ActivityWitness> **
**	****	****<j:ActivityOfficial.Enforcement j:id="****b2****">**
**	****	****	****<j:RoleOfReference.Person j:ref="****p1****"/> ****	****	****	****	**
**	****	****<j:EnforcementOfficialTypeText>Investigator</j:EnforcementOfficialTypeText>**
**	****	****</j:ActivityOfficial.Enforcement>**
**	****</j:Activity>**
**<WIJIS>**

**Notes:**
The XML instance for the Role.Of solution would thus maintain the Person and Organization objects at the SuperType (WIJIS) level. Role.Of objects would reference the associated Person and Organization object allowing object separation.

## Role-Of Issues

- Does not handle all possible associations between objects.
- E.g. GJXDM field EmploymentEmployer could be modeled as RoleOf.Employer.
- However
- EmploymentAssignedUnit.Organization, describing association between person object & assigned unit in an organization
-  Not a good fit for Role.Of modeling
- Nor does EmploymentLocation
- An association between person and organization location

## NDEx Approach

- NDEx proposes to handle missing associations in GJXDM via:
- Single Association Table
- Codes
**AssociationCodeOrganizationType**
- Includes codes for
- Unknown, Other, None, Affiliate, Contractor, & Sub-contractor.
**AssociationCodeOrganizationLocation**
- Include codes for Unknown, Other, None, Physical Street Address, Mailing Address and Billing Address.
**AssociationCodeOrganizationPerson**
- Includes codes for Unknown, Other, None, Owner, Full-time Employee, Part-time Employee, Contractor and Member.
**Etc...**
- Approach is a hybrid
- IncidentVictim & IncidentWitness handled via references instead of codes describing association of person with incident.

**Notes:**
To address this problem, NDEx (the FBI’s National Data Exchange) has proposed using a single association table with an AssociationSubjectReference, AssociationObjectReference and Association Code.

## Single Association Table UML

**NDEx proposes a single association table using references & codes **

## Single Association Table Instance

**<!-- Person Location Association -->**
**<i:Association j:effectiveDate="1999-07-15">**
**	****<i:AssociationSubjectReference j:ref="PID1"/>**
**	****<i:AssociationObjectReference j:ref="LID1"/>**
**	****<i:AssociationCode.PersonLocation>**
**	****	****3**
**	****</i:AssociationCode.PersonLocation>**
**</i:Association>**

**Notes:**
To address this problem, NDEx (the FBI’s National Data Exchange) has proposed using a single association table with an AssociationSubjectReference, AssociationObjectReference and Association Code.

## Question

- Can GJXDM constructs such as IncidentVictim & IncidentWitness be eliminated in favor of association codes?
- Would lose data related to association
-  WitnessAccountDescriptionText field.
- More modeling could handle this problem
-  Document object with PersonActivity association coded as “statement”.

## Associations - I

- In theory, many possible associations between GJXDM objects exist
**For indexing, most important associations derive from relationships to activity**
**ActivityPerson (victim, witness),**
**ActivityProperty (seized property) **
**ActivityOrganization (ActivityClearer.Organization)**
**ActivityDocument (incident report)**
**ActivityLocation (ActivityLocation)**
**Associated GJXDM attributes are in parentheses.**

**Notes:**
There are also a number of direct relationships of interest between objects: PersonOrganization (EmploymentEmployer), OrganizationPerson (OrganizationPrincipalOfficial), PersonContactInfromation (PersonDayContact), OrganizationContactInformation (OrganizationDayContact), PersonLocation (EmploymentLocation), OrganizationLocation (OrganizationLocation), PropertyPerson (PropertyTitleHolder.Person), PropertyLocation (PropertyLocation).

There are also relationships between the same object, called reflexive assocations: PersonPerson (PersonAlias), OrganizationOrganization (OrganizationSubunit), DocumentDocument (document correction) and ActivityActivity (previous incident).

## Associations - II

- There are also many direct relationships of interest
-  PersonOrganization (EmploymentEmployer)
- OrganizationPerson (OrganizationPrincipalOfficial)
- PersonContactInfromation (PersonDayContact)
- OrganizationContactInformation (OrganizationDayContact)
- PersonLocation (EmploymentLocation)
- OrganizationLocation (OrganizationLocation)
- PropertyPerson (PropertyTitleHolder.Person)
- PropertyLocation (PropertyLocation)

## Associations - III

- There are also relationships between the same object
- Referred to as Reflexive assocations
- PersonPerson (PersonAlias)
- OrganizationOrganization (OrganizationSubunit)
- DocumentDocument (document correction)
- ActivityActivity (previous incident).

## Associations

**Notes:**
There are also a number of direct relationships of interest between objects: PersonOrganization (EmploymentEmployer), OrganizationPerson (OrganizationPrincipalOfficial), PersonContactInfromation (PersonDayContact), OrganizationContactInformation (OrganizationDayContact), PersonLocation (EmploymentLocation), OrganizationLocation (OrganizationLocation), PropertyPerson (PropertyTitleHolder.Person), PropertyLocation (PropertyLocation).

There are also relationships between the same object, called reflexive assocations: PersonPerson (PersonAlias), OrganizationOrganization (OrganizationSubunit), DocumentDocument (document correction) and ActivityActivity (previous incident).

## The WIJIS Approach

## WIJIS Solution

- Extend GJXDM to handle object relationships using multiple association tables
- One for each of the associated objects
- Facilitates mapping for indexing databases
- Semantics of the associations are more easily modeled

## Multiple Association Tables

**Notes:**
WIJIS would propose handling object relationships using multiple association tables, one for each of the associated objects. The association objects would map to join tables in the RDB and would be used for searching (find all the people listed at a given residence).

## Schema Snippet - I

**...**
**<xs:complexType name="AssociationType">**
**	****<xs:attribute ref="j:ref"/>**
**</xs:complexType>**
**<xs:complexType name="ActivityActivityType">**
**	****<xs:complexContent>**
**	****	****<xs:extension base="ext:AssociationType">**
**	****	****	****<xs:attribute name="code" type="codes:ActivityActivityCodeType" default="none"/>**
**	****	****</xs:extension>**
**	****</xs:complexContent>**
**</xs:complexType>**

**Notes:**
WIJIS would propose handling object relationships using multiple association tables, one for each of the associated objects. The association objects would map to join tables in the RDB and would be used for searching (find all the people listed at a given residence).

## Schema Snippet - II

**<xs:simpleType name="ActivityActivityCodeType">**
**	****<xs:restriction base="xs:token">**
**	****	****<xs:enumeration value="unknown"/>**
**	****	****<xs:enumeration value="other"/>**
**	****	****<xs:enumeration value="none"/>**
**	****	****<xs:enumeration value="activity_previous_incident"/>**
**	****	****<xs:enumeration value="activity_related_incident"/>**
**	****	****<xs:enumeration value="activity_previous_court"/>**
**	****	****<xs:enumeration value="activity_related_case"/>**
**	****	****<xs:enumeration value="activity_related_activity"/>**
**	****</xs:restriction>**
**</xs:simpleType>**

**Notes:**
WIJIS would propose handling object relationships using multiple association tables, one for each of the associated objects. The association objects would map to join tables in the RDB and would be used for searching (find all the people listed at a given residence).

## Schema Snippet - III

**<xs:complexType name="ActivityType">**
**	****<xs:complexContent>**
**	****	****<xs:extension base="j:ActivityType">**
**	****	****	****<xs:sequence>**
**	****	****	****	****<xs:element ref="ext:ActivityActivity" />**
**	****	****	****	****<xs:element ref="ext:ActivityDocument“ />**
**	****	****	****	****<xs:element ref="ext:ActivityLocation" />**
**	****	****	****	****<xs:element ref="ext:ActivityOrganization" />**
**	****	****	****	****<xs:element ref="ext:ActivityPerson" />**
**	****	****	****	****<xs:element ref="ext:ActivityProperty" />**
**	****	****	****</xs:sequence>**
**	****	****</xs:extension>**
**	****</xs:complexContent>**
**</xs:complexType>**

**Notes:**
WIJIS would propose handling object relationships using multiple association tables, one for each of the associated objects. The association objects would map to join tables in the RDB and would be used for searching (find all the people listed at a given residence).

## XML-DB Instance

**<WIJIS >**
**	****<Activity id="****ACTID1****“>**
**	****	****<ActivityPerson ref=“****PID1****” code=“witness”/>**
**	****	****<ActivityPerson ref=“****PID1****” code=“enforcement_official”/>**
**	****</Activity>**
**	****<Person id="****PID1****" >**
**	****	****<PersonName>**
**	****	****	****<PersonFullName>Bob</PersonFullName>**
**	****	****</PersonName>**
**	****	****<PersonOrganization ref=“****OID1****” code=enforcement_official”/>**
**	****</Person>**
**	****<Organization id="****OID1****>**
**	****	****<OrganizationORID><ID>1234</ID></OrganizationORID>**
**	****	****<OrganizationName>Local PD</OrganizationName>**
**	****</Organization>**
**</WIJIS>**

**Notes:**
In XML-DB, each object (to include association objects) are separated and cross-referenced as needed.

## Object-Relational Map

- Very straightforward

**CREATE TABLE WIJIS (**
**	****WIJISID INTEGER PRIMARY KEY,**
**	****reportingOrganizationText VARCHAR(124) NOT NULL,**
**	****reportedDate DATE NOT NULL,**
**	****reportedTime TIME NOT NULL,**
**	****sourceIDText VARCHAR(124) NULL,**
**	****sensitivityText VARCHAR(124) NOT NULL,**
**	****commentText VARCHAR(124) NULL,**
**	****distributionText VARCHAR(124),**
**	****RECEIVEDDATE DATE NOT NULL,**
**	****RECEIVEDTIME TIME NOT NULL**
**    ****	****)**
**CREATE TABLE ACTIVITY (**
**	****ACTID INTEGER PRIMARY KEY****,**
**	****WIJISID INTEGER NOT NULL,**
**	****ActivityID VARCHAR(12) NOT NULL,**
**	****ActivityDate DATE NOT NULL,**
**	****ActivityEndDate DATE NULL,**
**	****FORIEGN KEY (WIJISID) REFERENCES WIJIS (WIJISID)**
**	****)**

**Each object has table with Primary & Foreign key related to parent object **

**Notes:**
The object-relational map is then very straightforward. Each object has a table with a PRIMARY KEY and a FOREIGN KEY related to the parent object.

## Association Mapping

**Notes:**
The association objects are mapped in a similar manner but have two FOREIGN KEYS, one for the subject and another for the object of the association.

## Association Mapping

- Mapped in a similar manner
- Have 2 foreign keys

**CREATE TABLE ACTIVITYACTIVITY (**
**	****CODE VARCHAR(24) NOT NULL,**
**	****ACTAID INTEGER PRIMARY KEY,**
**	****ACTID1 INTEGER NOT NULL,**
**	****ACTID2 INTEGER NOT NULL,**
**	****FOREIGN KEY (ACTID1) REFERENCES ACTIVITY (ACTID),**
**	****FOREIGN KEY (ACTID2) REFERENCES ACTIVITY (PERID)**** **
**	****)**

**Notes:**
The association objects are mapped in a similar manner but have two FOREIGN KEYS, one for the subject and another for the object of the association.

## XML-RPC Instance

- For queries, association codes are used for searching

**<?xml version="1.0" encoding="UTF-8"?>**
**<WIJIS_PersonSearch>**
**    ****<Person PersonName=”****Martha Stewart****" >**
**    ****	****<ActivityPerson code="****arrest_subject****"/>**
**    ****</Person>**
**</WIJIS_PersonSearch>For queries, **

**Notes:**
For queries, an XML-RPC approach would use the association codes for searching.

## Has It Become Too Complicated?

## Alternatives

**Notes:**
Given various combinations of Object Inclusion/Object Separation/Object Reference, Association Inclusion/Association Separation, and Role.Of approaches, we have found nine different file formats that might qualify as valid GJXDM documents (with minimal extensions to handle association tables). We have also found that, given the structure of different RMS databases, there might not be one best approach to generating GJXDM messages. In theory, all these different message types could be transformed  using XSLT. However, the proliferation of XML schemas is considered an anti-pattern to be avoided. 

## Does It Matter?

## Relational DB Storage

**Unstructured Storage **
- Entire XML document stored entirely as Character Large Object (CLOB).
- Provides
- rapid throughput
- document fidelity
- flexibility.
- Document processing can be expensive
-  Document Object Model (DOM)-level operations are   required.

**Notes:**
The current release of major relational databases (Oracle, Microsoft, IBM) provide direct XML support. For example, Oracle provides both unstructured and structured storage options. Since auditing and querying are of interest in criminal justice, both approaches will probably be needed. XQuery can handle multiple XML-DOCs and might eventually replace XSLT. In that case, multiple message models would be stored in the RDB and queried as virtually the same data. WIJIS currently has a POC running to determine the issues related to this approach.

## Relational DB Storage

**Structured Storage**
- Provides many advantages
- Optimized memory management
- Xquery and Xpath capabilities
- Reduced storage requirements
- B-tree indexing and in-place updates.
- Schema annotations used to control storage of XML collections:
**CLOB** - XML text stored in a Character Large Object.
**VARRAY in a LOB - **Each element converted into database-native object.
**VARRAY as Nested Table**
- Each element converted into database native object
- Stored as set of rows in Index Organized Table (IOT).
**VARRAY of REF XMLType as LOB** - Each element treated as separate CMLType value.
**VARRAY of REF XML Type as Nested Table** - Each element treated as separate CMLType value stored as Nested Table

**Notes:**
The current release of major relational databases (Oracle, Microsoft, IBM) provide direct XML support. For example, Oracle provides both unstructured and structured storage options. Since auditing and querying are of interest in criminal justice, both approaches will probably be needed. XQuery can handle multiple XML-DOCs and might eventually replace XSLT. In that case, multiple message models would be stored in the RDB and queried as virtually the same data. WIJIS currently has a POC running to determine the issues related to this approach.

## Questions?