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

["Roger L. Costello" <costello@mitre.org>]

 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