[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: A Systematic Approach to using Simple XML Vocabularies to

• To: "'Roger L. Costello'" <costello@m...>, xml-dev@l...
• Subject: RE: A Systematic Approach to using Simple XML Vocabularies to Implement Large (Complex) Systems
• From: "Bullard, Claude L (Len)" <len.bullard@i...>
• Date: Thu, 16 Dec 2004 10:07:00 -0600

A names record with a Master Names index is the most common 
approach in records management systems now.  (Hint:  the index 
is part of building relationship models so a name can be used 
in multiple record types).

Hair color is not immutable.  Nor is hair.  You'll find out.  
Transient properties have history files (your address will, 
your hair color will; your eye color won't).  One advantage 
of any broadcast approach is that it is a snapshot and a 
reason to insist on timestamps and even rate of change information.

The property bag approach is the midway approach to full up Groves.

Slowly but surely, the Hytime guys are winning. :-)

len


From: Roger L. Costello [mailto:costello@m...]

Hi Folks,

Yesterday I received an approach from Naz Irizarry.  His approach
has some similarities with Peter's approach.

Before describing Naz's approach let me make some observations 
about this simple XML object:

<Person id="RLC>
   <Name>Roger L. Costello</Bag>
   <HairColor>red</HairColor>
   <SSN>310-60-1234</SSN>
</Person>

OBSERVATIONS

1. The above XML represents information about a Person "object" with 
   Name, HairColor and SSN "properties".

2. The Name, HairColor, and SSN properties are "physics".  That is, 
   they are basic, immutable aspects of an object.

3. These properties could be used by many objects.  For example,
   they could be used to describe an "Employee":

<Employee id="RLC>
   <Name>Roger L. Costello</Bag>
   <HairColor>red</HairColor>
   <SSN>310-60-1234</SSN>
</Employee>

or they could be used to describe a "Student":

<Student id="RLC>
   <Name>Roger L. Costello</Bag>
   <HairColor>red</HairColor>
   <SSN>310-60-1234</SSN>
</Student>

and many, many other ways.

Thus, many different types of objects may have the same properties.

4. The properties may be aggregated with other type-specific
   properties.  For example, the Employee type may have a specific 
   property called EmployeeID:

<Employee id="RLC>
   <Name>Roger L. Costello</Bag>
   <HairColor>red</HairColor>
   <SSN>310-60-1234</SSN>
   <EmployeeID>10981</EmployeeID>
</Employee>

5. The type of an object may be inferred simply from the aggregation 
   of properties.  For example, if I told you:

   "The object has 4 tires and a steering capability."

   You might infer that the object is an automobile.  If I told you:

   "The object has 4 tires, a steering capability and wings."

   You might infer that the object is an aircraft.

6. In the real world relationships between objects change. For example, 
   when I drove to work this object:

<Person id="RLC>
   <Name>Roger L. Costello</Bag>
   <HairColor>red</HairColor>
   <SSN>310-60-1234</SSN>
</Person>

established a relationship to this object:

<Auto id="RLC-Avalon">
   <Model>Avalon</Model>
   <Make>Toyota</Make>
   <Year>2004</Year>
</Auto>

Namely, the relationship established was:

   "The RLC Person is driving the RLC-Avalon Auto."

Once I got to work that relationship ceased to exist.

Thus, it is useful to provide for dynamic relationships.

7. Consider again the Person object:

<Person id="RLC>
   <Name>Roger L. Costello</Bag>
   <HairColor>red</HairColor>
   <SSN>310-60-1234</SSN>
</Person>

   This XML defines a "static" relationship between the Person "type" 
   and the Name, HairColor, and SSN "properties".  That is, by nesting 
   <Name>, <HairColor>, and <SSN> within <Person> I am "hardcoding" 
   a dependency between the <Name>, <HairColor>, <SSN> properties and 
   the <Person> type.  

8. Consider the coupling of a Person object and an Auto object:

<Person id="RLC>
   <Name>Roger L. Costello</Bag>
   <HairColor>red</HairColor>
   <SSN>310-60-1234</SSN>
</Person>
<Auto id="RLC-Avalon">
   <Model>Avalon</Model>
   <Make>Toyota</Make>
   <Year>2004</Year>
   <DrivenBy href="#RLC"/>
</Auto>

   Note how the Auto object references the Person object
   using <DrivenBy href="#RLC"/>

   This defines a "static" relationship between the 
   Person object and the Auto object. I am "hardcoding" a 
   dependency between these two objects.  

9. I will stipulate that in large systems "agility" of data 
   is important: 
      - At "run-time" it is useful to be able to 
        aggregate properties and denote them to 
        be of a particular type.
      - At run-time it is useful to be able to 
        extend the properties of an object.  
      - At run-time it is useful to be able to 
        add relationships from one object to 
        another object, and to be able to 
        remove relationships.  

With the above observations in mind, I am now ready to 
present Naz's approach.

THE NAZ IRIZARRY APPROACH

The key feature of Naz's approach is the Bag.  Think of a Bag as an
"object".  An object has "properties".  An object has a "type".  And an
object has "relationships" to other objects.  Thus, a Bag has three parts:

1. A collection of data (these are the properties of the object).
2. An indication of the type (the type of the object).
3. Relationship information.

For example, here's how to express information about Roger L. Costello 
and his relationship to The MITRE Corp.

<bag id="RLC">
    <is-a instanceOf="Person"/>
    <has property="Name">Roger L. Costello</has>
    <has property="HairColor">Red</has>
    <has property="SSN">310-60-1234</has>
    <refersTo xlink:role="employed-by"
              xlink:href="#MITRE"/>
</bag>

The way to read this is, 

    "This is information about an object which has three properties - Name,
     Age, and SSN.  The type of the object is 'Person'.  It is related to
     another object (MITRE) by the relationship, 'employed-by'."

With the Bag approach properties are dynamically composed. The
same properties can be associated with a different type.  Further, the
properties can be associated with multiple types.  

Here the Name, HairColor, SSN properties are associated with an 
"Employee" type and a "Person" type:

<bag id="RLC">
    <is-a instanceOf="Employee"/>
    <is-a instanceOf="Person"/>
    <has property="Name">Roger L. Costello</has>
    <has property="HairColor">Red</has>
    <has property="SSN">310-60-1234</has>
    <refersTo xlink:role="employed-by"
              xlink:href="#MITRE"/>
</bag>

So properties are things that can be aggregated, typed, and related to 
other objects ... dynamically.  In a large, dynamic system this agility 
is crucial (I assert).  This is called "opportunistic composition and 
relationships".

In my last message I issued a challenge: how can simple vocabularies be used
to construct an Invoice for the purchase of a Book.  Here's how to implement
the Invoice using Naz's approach:

<bag id="RLC">
    <is-a instanceOf="PostalAddress"/>
    <has property="Addressee">Roger L. Costello</has>
    <has property="Street">38 Boylston St.</has>
    <has property="City">Boston</has>
    <has property="State">MA</has>
    <has property="Zipcode">01320</has>
    <refersTo xlink:role="purchased"
		  xlink:href="#Bach"/>
</bag>

<bag id="Bach">
    <is-a instanceOf="Book"/>
    <has property="Title">Illusions</has>
    <has property="Author">Richard Bach</has>
    <has property="Date">1977</has>
    <has property="ISBN">0-440-34319-4</has>
    <has property="Publisher">Dell Publishing Co.</has>
    <refersTo xlink:role="purchased-by"
		  xlink:href="#RLC"/>
</bag>

<bag>
    <is-a instanceOf="Invoice"/>
    <refersTo xlink:role="contains"
              xlink:href="#RLC"/>
    <refersTo xlink:role="contains"
              xlink:href="#RLC"/>
</bag>

The advantages of the Bag approach are:

1. Opportunistic composition and relationships.
2. Highly scalable.
3. Well-suited in cross-domains.
4. Well-suited in evolving systems.
5. A flexible, dynamic Web of data is created.

The disadvantages of the Bag approach are:

1. It requires more skill to build applications because
   properties and relationships are not fixed.  We are 
   all comfortable with writing applications that can 
   process this:

   <Person>
      <Name>Roger L. Costello</Bag>
      <Age>39</Age>
      <SSN>310-60-1234</SSN>
   </Person>

   But it is much more challenging to write an application 
   that can process a {Name, Age, SSN} collection which in 
   one part of the system represents a Person, in another 
   part of the system represents an Employee, etc.
   Further, the relationships between this object and other
   objects may dynamically change (see observation #6 above).

2. A flexible query and navigation language is required.  The
   language must allow navigation based upon dynamically 
   established relationships.  For example,

   "[From the Person object] Navigate to the "driving" object."

   See Observation #6 above.  Unfortunately, XPath provides a
   fixed (static) set of navigation capabilities - child, ancestor,
   preceding-sibling, etc.  [I assert] These are inadequate in a 
   large, dynamic system.

Comments?  /Roger






-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>

• Prev by Date: RE: draft-rsalz-qname-urn
• Next by Date: PLEASE do not cross-post xml-dev to XQuery comments list
• Previous by thread: Re: A Systematic Approach to using Simple XML Vocabulariesto Implement Large (Complex) Systems
• Next by thread: RE: A Systematic Approach to using Simple XML Vocabularies to Implement Large (Complex) Systems
• Index(es):
  • Date
  • Thread