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

["Thomas B. Passin" <tpassin@home.com>]

I partly agree with you on both counts - a model is needed, and work can be
done on requirements now.  I have embedded more replies below.

[Lars Marius Garshol]
>
> * Graham Moore
> |
> | I think the API should be related to the model/ wait until thats done,
> | otherwise it is ambiguous as to what you are manipulating.
>
> * Thomas B. Passin
> |
> | I think that some useful work could be done before that happens.
>
> I think you are right, and I think we need a standardized API for
> topic maps. There is also, however, no question that Graham is right
> in that we must get the model nailed down before we can do the API.
> This tradition (from SGML, XML, and topic maps) of doing the model
> last just has to be broken away from.
>
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.
That won't be everything needed, but I predict it could be significant.

> ...
> The second thing to be done is to draw up a requirements document.
> This should really be done by whoever is appointed to do this work,
> but I think anyone should feel free to come up with proposals.
>

Yes, I'm trying to stimulate proposals.

>...

> | For example, users will need to see a list of basename strings (so
> | they can make a selection).  That's independent of the details of
> | the model beyond the bare fact that there are such things as names
> | attached to topics.
>
> This is true, but one needs a model specification in order to be able
> to settle on such things as what classes the API should have, and so
> it really is hard to get started before there is a model in place.
>
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.  It is either going to return the label that the
user selected, or an associated value or ID.  The system will need to find
or apply the topic, scope, etc. using only what was returned from the
browser.

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.

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.

There are a myriad of such decisions that could be made without the
completion of the model, all related to how the user would interact with the
system.  They could be prototyped or mocked up using existing engines.  Even
a decision about whether the calls should be object-oriented or not could
conceivably be put off (oh, horrors!), since instance.method(parm) could be
converted to method(structure,parm) if one didn't want to go O-O.  (Of
course, I'm expecting an object-oriented API, I'm just emphasizing that it
is possible to be flexible and still make useful progress).

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

I think this supports what I have been saying.  If it's to be kept separate,
why do we have to wait?

> | Another example is whether a request to return a topic should return
> | an object identifier or the topic's id.
>
> It should get an object. As long as you are in an API that is the only
> thing that makes sense.
>
As I said above, there has to be a way to get a string to display, not an
object.  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).  But if there were a need, it could
be in a different API call.  We would wait until the model was ready to
define the second call, but we could proceed on the first now.

> | Should a request for a topic ask for it by id or by object
> | identifier, or should there be methods for both?
>
> There should be methods for both.
>
More support for my suggestion.

> | There are many issues like these that can be worked out before the
> | detailed model is done.  It would be worth getting started now, I
> | think.
>
> I wouldn't oppose anyone starting to collect requirements now, but I
> personally don't think I would have much spare energy to contribute to
> this given that the work on the model and TMQL and TMCL is just
> starting. Probably most others will be in the same position.
>
I repeat that I am suggesting starting work on (the requirements for) a
***user-level*** API and going as far as possible without much of a model .
The remainder would have to depend on the model.  What proportion of the
whole that would be remains to be seen, but I predict that it could be less
than 50%.

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?

Regards,

Tom P


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/