Re: [xtm-wg] A challenge on "the graph"

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Lars Marius Garshol
|
| What I mean is that UML describes classes with methods, which is what
| you have when you've finished your design. 

* W. Eliot Kimber
| 
| No, UML *allows* classes with methods, but there is no requirement
| that a UML class have any methods.

True. It would be a rare API design that ended up with no methods,
though.

| Thats how you can have a UML static data model: classes with only
| attributes but no methods. 

Right. If we can do that I'll be a lot happier.

| But in any case *I DEMAND AN API* so you will have to specify
| methods somewhere in the processing model.

Then we have precisely opposing demands. 

An API is a VERY much larger job than an abstract data model, since it
will have to consider heaps of issues that you can stay out of when
you only specify the data model. Some of these are:

 - with an API change enters the picture and you have the entire
   Pandora's box of concurrent modification, illegal operations and
   whatnot to deal with and this is a veeery subtle area

 - you have to draw a demarcation line between just representing the
   information and providing utilities for conveniently working with
   the information, and you have to decide which of those utilities
   are appropriate to include and which are not

 - you will have to decide what kinds of lookups should be possible
   in the APIs and what should be left for TMQL

In short, to also do an API would expand the task enormously, and it
would gain nothing for TMQL. Therefore I think that it would make
vastly much more sense to do the abstract model first, and then to do
the API afterwards. (We _do_ need an API, but that will be a long and
hard job. I should know, I've just spent 12 months of my life as part
of a team that has created one.)
 
| If this effort does not result in a standard default API for accessing
| topic maps it will have been wasted effort. IMNSHO.

I agree, but it doesn't mean that it all has to be done in one go.
Just look at the infoset and the DOM. It makes a LOT of sense to keep
those two separate. You wouldn't define XML-QL on top of the DOM, for
example.
 
| Look at the work I did back in Paris. 

I will. Should have thought of that.

| I'm yelling because it appears that the weeks of work a bunch of us
| did on this has been COMPLETELY IGNORED!!!!!. 

Eliot, I'm a finite being. I looked at it a long time ago, and then I
looked away. I didn't realize that now, X months later, I would find
it useful. 

| Why? The depth of my frustration cannot be overstated. It's
| maddening.

I know precisely how you feel. You have of course, like all the other
members of this list, read my canonical XTM proposal?
 
| I DO OBJECT TO THE CONSTANT MISREPRESENTATION OF UML AND THE
| CONTINUED QUESTIONING OF ITS UTILITY IN THE FACE OF ESTABLISHED
| EXISTENCE PROOFS.

I just did a very quick retreat when I realized I didn't know what I
was talking about (see my previous emails). So please relax.

--Lars M.


------------------------ 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/