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

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

* W. Eliot Kimber
| 
| I also agree with your list of requirements for the static model part of
| the processing model.

Then I don't think we are all that far apart.
  
| Here is our point of disagreement: Lars and I appear to agree that
| we must have a static data model that describes the structures that
| some API would expose

We do.
 
| But Lars does not want an API.

I _do_ want an API. I just want it kept separate from the processing
model, and I want it to be done after the processing model.

| I also feel very strongly that without at least some sort of minimal
| standard API in the spirit of the DOM, that the world at large and
| our marketing effort in particular will not be well served.
 
I agree completely. I think a very large proportion of topic map
applications will have some code written especially for them, and if
this code can be based on standards like a TMQL and a TM API users
will be far more independent of their vendors.

| If the DOM has taught us anything it is that, to implementors, an
| API with no underlying data model is better than a data model with
| no API.

That is true, but I don't think it's a very good argument for why we
should do things in the wrong order. What's wrong with first
completing the data model and then doing the API?

| If there is no standard API, then I either must completely rework
| every integration of every topic map tool I may want to use or I
| must define my own topic map API and then wrap every tool I
| integrate into it, at the cost of effort and efficiency that would
| have been avoided had there been a standard API in the first place.
 
Exactly.

| Note that I am not suggesting we define the full API that a complete
| topic map system would expose (and where, for example, you might
| have issues of concurrency). 

I see no way around that. If you support modification you have
concurrency issues immediately. Even something as simple as an
iterator over all topics in a topic map will be affected by this, and
even in a single-threaded environment. For example, what should happen
if while iterating over the topics you delete some of them, or add new
ones? 

| I'm only talking about the basic get/set methods for the classes in
| the data model,

In the data model it's the add and remove methods that are the most
interesting, and those raise concurrency issues immediately. (Add
topic, remove topic, add base name, remove base name, add subject
indicator, remove subject indicator, etc.) Some of the set methods
will also have synchronization issues, but those can probably be left
to implementors to sort out.

| I think that this level of API pretty much falls out of any static
| data model and should not pose any great difficulty of
| specification--if we agree on the data model, the API should pretty
| much be an exercise in typing.

Don't you believe it! This API you are describing will be subject to
all the problems I listed, and more besides. You wanted utilities, for
example, and for some of those one will have to decide whether they
belong in the core APIs or not. Especially for associations and assoc
roles that may be difficult to work out.
  
| But I don't think it's sufficient to say that resources are strings,
| you must say "resources are whatever you get when you resolve the
| string, whatever that might be." To say otherwise is to perpetuate
| the madness.

You are misinterpreting me. I wanted to represent resources by their
URIs, which are strings. Beyond that the model would have to say
precisely what you say.

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