RE: [xml-dev] Embedded-Grammar&Components Design Approach [Was: A bunch of components, but no mandated organization - reasonable?]

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Embedded-Grammar&Components approach = RDF?

 

Kind Regards,

Joseph Chiusano

Booz Allen Hamilton

Strategy and Technology Consultants to the World

 

---

From: Roger L. Costello [mailto:costello@mitre.org]
Sent: Monday, January 17, 2005 7:46 AM
To: 'XML Developers List'
Subject: [xml-dev] Embedded-Grammar&Components Design Approach [Was: A bunch of components, but no mandated organization - reasonable?]

 Hi Folks,

Last week I raised this issue:

Suppose that there exists a collection of components.  Assume the meaning of each component is understood.  If I dynamically assemble some components, and send it to you, will you be able to dynamically understand my assembly?

An example was presented which convincingly suggested that no, in the general case, you will not be able to understand a dynamically created assembly:

Consider these three components: 'John', 'Shot', 'Roger'. Clearly, these carry different meanings depending on the order.

Thus, despite knowing the meaning of each individual component, more information is necessary for the receiver to effectively process a dynamic assembly of components:

The confusion is among [which component is] the actor, the object, and the action.

What is needed is the grammar, e.g.,

    homicide :: actor action object

and then a mapping from grammar items to information components. That is, identify which component is the actor, which component is the action, and which component is the object, e.g.,

    actor  --> John
    action --> Shot
    object --> Roger

A design emerges:

<message>
    <grammar id="homicide">
        <actor  idref="John"/>
        <action idref="Shot"/>
        <object idref="Roger"/>
    </grammar>
    <Person id="John">
        <age>24</age>
        <address>101 Curl Drive, Columbus, Ohio</address>
    </Person>
    <Action id="Shot"/>
    <Person id="Roger">
        <age>39</age>
        <address>38 Tremont St, Boston, MA</address>
    </Person>
</message>

Things to note:

1. The message carries within itself the instructions for interpreting it.
2. That is, the grammar is embedded within the message.
3. The message contains a list of independent components, which are related by the grammar.

In other words, the instance document is comprised of a grammar that provides instructions  for  interpreting the succeeding components.  Here is the general format for instance documents following this approach:

<message>
   <grammar id="...">
       ...
   </grammar>
   -- component --
   -- component --
   ...
</message>

Below is another example.  It shows an instance document which contains information about a financial transaction - 'John' 'Purchased' a 'Smith-Wesson Revolver':

    actor  --> John
    action --> Purchased
    object --> Smith-Wesson Revolver

<message>
    <grammar id="financial-transaction">
        <actor  idref="John"/>
        <action idref="Purchased"/>
        <object idref="Smith-Wesson Revolver"/>
    </grammar>
    <Person id="John">
        <age>24</age>
        <address>101 Curl Drive, Columbus, Ohio</address>
    </Person>
    <Action id="Purchased"/>
    <Gun id="Smith-Wesson Revolver">
        <serial-no>3290-4389-12</serial-no>
        <cartridge>3mm</cartridge>
    </Gun>
</message>

I will refer to the above  style of design as the Embedded-Grammar&Components approach.

Advantages of the Embedded-Grammar&Components Design Approach

1. Loosely coupled components: imagine creating a repository of independent components.  They can be reused with a variety of different grammars.  Grammars can be shuffled in and out, all the while using the same components.  In a dynamically changing enterprise, this is a powerful paradigm. 

In the above examples we see the same Person component being used with two different grammars.

2. Flat data: the structure of instance documents is flat.  Namely, it is simply the grammar followed by a list of components. 

Flat data is good data.

3. Explicit relationships: in the above examples the relationship between the actor and the object is explicitly specified ("Shot" in the first example, and "Purchased" in the second example).

Explicitly stating the relationships between components is a good thing. Implicit relationships are subject to misinterpretation.

4. Flexible, Extensible, Powerful: new grammars can be created. New components can be created.  A component can be used with many grammars.  Grammars and components can be mixed-and-matched.

I have listed advantages of the Embedded-Grammar&Components approach.   Can you think of other advantages?  Can you list its disadvantages?   Other comments? 

/Roger