Many applications require business entities such as employees and organizations to be modeled as objects. Over time, it becomes apparent that there are similarities between the information stored about individuals and the information stored about groups. In particular, contact information is often stored about both, but perhaps that information is stored in different ways. In Analysis Patterns: Reusable Object Models, Addison-Wesley, 1996, Martin Fowler models this relationship as a single business entity known as a ‘Party’. The Party is an entity that has a name, location, and contact information stored about it. In this pattern, Party becomes an abstract base class of both the Person class and the Organization class. For the purposes of our example, a Person is simply a Party with a Social Security number, and an Organization is a Party that contains a member list of other parties. Figure 19.1 diagrams the relationship between the object types modeled in party.xsd.
The sample XML schema in Listing 19.12 models this pattern as well, but it represents the relationships between Party and its derived types by using the facilities of XML Schema rather than an object model. In this example, we have added another type to the model, called Role. The Role type is represented in the XML schema by the roleType complex type. A Role represents a business title or position. Such a role might be filled over time by different individuals, but it maintains its own contact information. For example, System Administrator is a role with an e-mail address of ‘[email protected]’.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace= "http://www.XMLSchemaReference.com/Examples/Ch19/" xmlns="http://www.XMLSchemaReference.com/Examples/Ch19/" xmlns:party="http://www.XMLSchemaReference.com/Examples/Ch19/" elementFormDefault="qualified"> <xsd:annotation> <xsd:documentation xml:lang="en"> This XML Schema Document describes the components that represent parties and organizations in an OO fashion. It is derived from Martin Fowler's Party pattern in "Analysis Patterns" by Addison-Wesley. </xsd:documentation> </xsd:annotation> <xsd:element name="organization" type="party:organizationType"/> <xsd:complexType name="addressType"> <xsd:annotation> <xsd:documentation xml:lang="en"> A mailing address for a party. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="street" type="xsd:string" /> <xsd:element name="city" type="xsd:string" /> <xsd:element name="state" type="xsd:string" /> <xsd:element name="zip" type="xsd:decimal" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="partyType" abstract="true"> <xsd:annotation> <xsd:documentation xml:lang="en"> Abstract data type for a business entity with a name, location, and contact information. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="name" type="xsd:string" /> <xsd:element name="address" type="party:addressType" /> <xsd:element name="email" type="xsd:string" /> <xsd:element name="phone" type="xsd:string" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="partiesType"> <xsd:annotation> <xsd:documentation xml:lang="en"> This is a list of parties, whatever their true type might be. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="party" type="party:partyType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="personType"> <xsd:annotation> <xsd:documentation xml:lang="en"> This type represents a person or individual. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:extension base="party:partyType"> <xsd:sequence> <xsd:element name="ssn" type="xsd:string" /> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="roleType"> <xsd:annotation> <xsd:documentation xml:lang="en"> This type represents a role in an organization (ex. CEO). </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:extension base="party:partyType"> <xsd:sequence> <xsd:element name="description" type="xsd:string" /> <xsd:element name="person" type="party:personType" /> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="organizationType" > <xsd:annotation> <xsd:documentation xml:lang="en"> This type represents an organization within a company, including its employees and units. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:extension base="party:partyType"> <xsd:sequence> <xsd:element name="members" type="party:partiesType" /> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:schema> |
Using this XML schema, we can model an Organization object by using an instance document like the one in Listing 19.13. In this example, you are representing the Quality Assurance organization within a company. This organization happens to conveniently include one person, one role, and one unit or suborganization. That unit also includes a person.
<?xml version="1.0"?> <organization xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="://www.XMLSchemaReference.com/Examples/Ch19/" > <name>Quality Assurance</name> <address> <street>2000 Main St.</street> <city>San Rafael</city> <state>CA</state> <zip>94903</zip> </address> <email>[email protected]</email> <phone>555-5000</phone> <members> <party xsi:type="personType" > <name>Jennifer Dix</name> <address> <street>11 Oak St.</street> <city>San Rafael</city> <state>CA</state> <zip>94903</zip> </address> <email>[email protected]</email> <phone>555-8888</phone> <ssn>333-33-3333</ssn> </party> <party xsi:type="roleType" > <name>Webmaster</name> <address> <street>45 Meadow Lane</street> <city>San Rafael</city> <state>CA</state> <zip>94903</zip> </address> <email>[email protected]</email> <phone>555-9000</phone> <description>System Administrator for the QA Web Site</description> <person > <name>Alexander Dix</name> <address> <street>45 Meadow Lane</street> <city>San Rafael</city> <state>CA</state> <zip>94903</zip> </address> <email>[email protected]</email> <phone>555-9000</phone> <ssn>444-44-4444</ssn> </person> </party> <party xsi:type="organizationType"> <name>QA Documentation</name> <address> <street>2000 Main St.</street> <city>San Rafael</city> <state>CA</state> <zip>94903</zip> </address> <email>[email protected]</email> <phone>555-5000</phone> <members> <party xsi:type="personType" > <name>Peter Parker</name> <address> <street>55 Pine Dr.</street> <city>San Rafael</city> <state>CA</state> <zip>94903</zip> </address> <email>[email protected]</email> <phone>555-2121</phone> <ssn>999-99-9999</ssn> </party> </members> </party> </members> </organization> |
Alternatively, you can create an XML instance document that does not validate against our new Organization schema. The instance document in Listing 19.14 does not match the Organization object you have defined because the xsi:type attribute of our organization member is not a type that derives from the partyType base.
<organization xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="://www.XMLSchemaReference.com/Examples/Ch19/" > <name>Quality Assurance</name> <address> <street>2000 Main St.</street> <city>San Rafael</city> <state>CA</state> <zip>94903</zip> </address> <email>[email protected]</email> <phone>555-5000</phone> <members> <party xsi:type="addressType"> <street>11 Oak St.</street> <city>San Rafael</city> <state>CA</state> <zip>94903</zip> </party> </members> </organization> |
Using the example XML schema and the org.xml instance document, the following sections consider the problem of creating objects from this model.
3.138.200.66