Re: [xtm-wg] User API - A new endeavour for topicmaps.org?

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

* Thomas B. Passin
|
| I partly agree with you on both counts - a model is needed, and work
| can be done on requirements now.

Good. Then I think you and I are at least in agreement.
 
| Agree, but users won't or shouldn't have to know much about the
| model, and I suggest that the requirements effort try to discover
| how much can be done with minimal knowledge of the model.

I'm not sure I like this idea of a user API. To me it sounds a bit
like an underpowered version of TMQL in the form of an API. Nor am I
convinced that it can be done without a data model API to base it on,
or a data model in terms of which its semantics can be explained.

I guess the way to convince me that I'm wrong would be to come up with
requirements that demonstrate that I am.
 
| I'm trying to stimulate proposals.

We have Kal's paper already, as well as the TM4J and K42 APIs. I'm
sure useful inspiration could be taken from these sources.
 
| Well, this is a good example. Consider a user at a brower (say) who
| selects the label (one of the names, presumably) of a topic or
| scope.  The browser is not going to contain an object from the topic
| map engine, and is not going to return an object.  

True, but now you're not working at the API level, so as far as I can
see this isn't relevant.

| The system will need to find or apply the topic, scope, etc. using
| only what was returned from the browser.

This is actually non-trivial, especially when you get to associations.
I don't think work on this level should be done without having the
model first.

| The requirements question would be this: should the application
| maintain a mapping the topic map to and those labels and IDs using
| proprietary code or using a API? This requirement might be
| something like "Return list of topics filtered by scope name".
| After the model is ready, we could decide what a "list" would really
| be.

It would have to be a collection, possibly ordered, of topic objects.
What those would look like is another matter. The problem is that you
can't specify how to apply the filtering and what it is applied to
without making assumptions about the model.

You can, of course, come up with the list of requirements.
 
| You, Lars, have said that we should wait for the model.  I say that
| we can decide whether to use a name string for retrieving topics,
| etc, or an ID, or something else - and we don't have to know the
| details of the objects to do this.

As long as it stays in the realm of requirements I agree with you.
 
* Lars Marius Garshol
|
| Another problem is that I think it is a requirement for the API that
| high-level operations like this one be kept separate from the data
| model.
 
* Thomas B. Passin
|
| I think this supports what I have been saying.  If it's to be kept
| separate, why do we have to wait?
 
Because you can't define those high-level operations without making
assumptions about the model. This is exactly the same as the TMQL
work, and, in fact, there is likely to be a significant functionality
overlap between an API like this and TMQL. What that means is that
they are subject to the same dependency on the data model.

* Lars Marius Garshol
|
| It should get an object. As long as you are in an API that is the only
| thing that makes sense.

* Thomas B. Passin
|
| As I said above, there has to be a way to get a string to display,
| not an object.

Of course, but you can get that once you have the object. You may also
want a number of other things from the topic, and if you get strings
that is made difficult.

| Perhaps there is never going to be a need to return an object, as
| long as they can be looked up quickly using an index or hash (sounds
| like heresy, but maybe it would be feasible).

To me it sounds like precisely what I want to avoid: an API contorted
by the lack of an underlying model.

| After all, all these problems will be solved since usable
| applications are going to be built.  How many times do people want
| to reinvent the solutions?

I think we are trying to make the same point here, but from different
points of view. If we do the API first and the model afterwards one of
the following will happen:

 a) we get a suboptimal API soon and have to stick with it forever

 b) we get a suboptimal API soon and reinvent an optimal one later

If we do the model first we can go straight from having no standard to
having a good one, and avoid the mess that the W3C got itself into
with the DOM.

Of course it would be best to be able to start the API work now, but
given that this community has already done things in the wrong order I
think the ordering problem needs to be fixed before anything else is
completed. 

You could of course argue that if we could start working on TMQL and
TMCL now there is no reason why we couldn't start on this as well, and
I guess you are to some extent right about that, but I don't think we
will be able to do all three at the same time, and the overlap between
the API and the model is much greater than it will be between TMQL or
TMCL and the model.

(I think that's my longest sentence ever. Sorry about that.)

--Lars M.


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/