[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xtm-wg] Summary of PM discussion
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC