[xtm-wg] Summary of PM discussion

[Sam Hunting <sam_hunting@yahoo.com>]

Fellow Topic Mappers:

I've tried to put all the ideas I've read on the PM
into a high-level summary as follows. 

This is compilation rather than advocacy.

Some of the ideas might not need to be here -- the
community should be the judge. Probably the best
feedback for this would be a more completely
thought-through version, rather than a lot of small
criticisms.

Since I'm using (sigh) ascii art, you need to use a
monospaced font and a line length of 70 to make it line
up properly.

The processing model thus far
-----------------------------
What is inside the box labelled "PM" is within the scope
of a PM (Processing Model) specification. 

XTM docs, an API(1), and TMQL are outside the scope of
a PM specification. The relation between the data model
and resources is specified abstractly with the ARS.

         +---------------------------------------+
  XTM -->|--->+---+  +---------------+           |    { TMQL[7]
doc(s)   |   /   /-->|     DM[3]     |<----------|<-- { API[8]
   [1]   |  /[2]/    |               |--->+---+  |     
         | +---+     +---------------+   /   /-->|---> XTM docs[9]
         | TR        |    ARS[4]     |  /[6]/    |
         |           +---------------+ +---+     |
         |                    ^        TR        |
         |                    |                  |
         +---------------------------------------+ 
          PM                  ^
                              |
                       [5] resources
              
This legend describes the parts of the PM:

[1] XTM document
[2] Transform rules take angle brackets and uptranslate
    to instance of the data model (Sam's table)
[3] The data model (DM). This space could be occupied by:
    a) SRN's "graph"
    b) Luis's object model
    c) the graph to come from Bernard's chercheurs
    d) one part of Eliot's UML work
[4] ARS (Abstract Requirements Syntax, Nikita) specifies
    relation between resources and the data model. (And
    maybe constraints on merging and arc endpoints?)
    
    The infoset-like approach (Lars) combines the ARS
    and the DM in prose (I think!)
    
[5] The relation between resources and the data model
    is outside the PM but abstractly specified in the ARS.
[6] Transform rules take instance of the data model and 
    downtranslate to XTM angle brackets (Annex F.)
[7] TMQL queries against the data model.
[8] API "gets" and "sets" the data model.
[9] Such an XTM document could be the results of a merge,
    or of a TMQL query, etc.

Syntax for the DM
-----------------

Then there is the question of syntax of the PM. Still against
the same diagram:

No.   Name Data model  Notation               comment
---   ---- ----------- ---------------------- ---------------
[1]   XTM  DOM/grove   DTD                    noli me tangere!
[2]   TR   N.A.        prose (SRN, Sam)       Published
           OO          UML (Eliot)            Published(3)
[3]   DM   graph       prose (SRN)            Published(DC)
           OO          UML (Luis)             Published(4)
           OO          UML (Eliot)            Post-Paris(3)
           grove       property set           Mentioned               
           graph       unknown (chercheurs)   Forthcoming
           N.A.        prose (Lars)(2)        Published(5)
           ??          EXPRESS (Eliot)        Mentioned
[4]  ARS               algebraic (Nikita)     Mentioned      
[6]  TR    N.A.        --                     As above?
[7]  TMQL  N.A.        XTM
[8]  API   N.A.        unknown (Eliot)

(There is also an expressed preference by some developers for
a node/properties approach, but no proposal yet. It's possible
that groves would satisfy this preference.)

It's surprising that ER diagrams aren't included ;-).

Another expressed concern is that the notation proposed
may bias the data model. For example, UML is by
definition an OO approach, yet systems that must manage
topic maps that are terabytes in size may not want the
overhead of objects.

On the other hand, if the notation and the data model truly
are orthogonal, then UML could be used to create a graph
data model.

Another concern with UML is the use of a constraint language.
Some say:

    * "UML depends on informal notes, so the notation really
       just boils down to prose and illustrations."
       
Others say:

    * "UML can avoid using notes by using a constraint 
       language, either the built-in OCL or a scripting
       language like Python."

A concern with OCL (Object Constraint Language) is whether 
it understands sets. (Python, of course, could be made to. 
This seems perilously close to an implementation, however.)

The question of a constraint language also applies to graph
approaches -- this seems to be what the Role Player Constraints
PSI is for, although constraints are currently (perhaps wisely)
only expressed in prose.

>From angle brackets to data model
---------------------------------
Then there is the question of how close ("isomorphic") the
data model should be to the XTM syntax. How this would affect
the notation chosen is not clear. Some say:

    * "The data model should stay close to the syntax since
       that is easier to understand."

Others say:

    * "The data model should abstract from the syntax for
       orthogonality" ("associations" are always processed
       as associations, for example).

>From the data model to the implementation
-----------------------------------------
There is also the question of how close the data model
should be to the implementation. Some say:

    * "UML diagrams are too close to the implementation."
    
and some say:

    * "A graph structure is too far from the implementation."

Still others advocate using UML notation to specify
the nodes and arcs of "the graph."

Glossary definition for the PM
------------------------------
There is also of course the question of an appropriate 
definition of the PM. Here is one starting point:

        "The XTM Processing Model defines the rules for
        processing XTM documents in order to reconstitute the
        meaning of the information they are intended to convey
        to their recipients."


Fear and loathing 
-----------------       
Finally there are various visceral likes and dislikes.
Some find nodes and arcs loathsome; others break out in
hives at the thought of UML diagrams; these feelings must
all be worked through in the course of the next month.

Conclusion
----------
Hope this helps focus the discussion. To repeat, a better
version of this entire document, rather than piecemeal
comments, would probably serve the community best. Any
takers?

S.

NOTES
-----
(1) This does not mean that the API is not important, just that
    a PM document should not include it. Options include
    simultaneous release of an API, a non-normative annex for 
    the API, and a technical report for the API.
(2) This approach blends the ARS and the DM.
(3) At some point after the first Paris meeting (2000)
(4) Immediately before the second Paris meeting (2001)
(5) "Straw man" on the recent list.

=====
<!-- "To imagine a language is to imagine a form of life."
     - Ludwig Wittgenstein, Philosophical Investigations -->

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text

------------------------ Yahoo! Groups Sponsor ---------------------~-~>
Do you have 128-bit SSL encryption server security?
Get VeriSign's FREE Guide, "Securing Your
Web Site for Business." Get it now!
http://us.click.yahoo.com/2cW4jC/c.WCAA/bT0EAA/2n6YlB/TM
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/