[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] User API - A new endeavour for topicmaps.org?
I think I get what Thomas wants now. There are three things (at least) 1. a model which *IS* the topicmap. 2. an api which allows a developer to manipulate a every part of that model. 3. a layer above the API that wraps up common user operations. (like create a named association etc). When developing k42 we found that these power interfaces are really useful. Hence com.empolis.topicmaps.helper.Builder is shipped with k42 to provide exactly that level that Thomas is talking about. Whether it has all the methods in there that address all the common user actions is different matter. cheers gra -----Original Message----- From: sentto-1553146-2411-993559919-gdm=stepuk.com@returns.onelist.com [mailto:sentto-1553146-2411-993559919-gdm=stepuk.com@returns.onelist.com ]On Behalf Of Thomas B. Passin Sent: 26 June 2001 13:53 To: xtm-wg@yahoogroups.com Subject: Re: [xtm-wg] User API - A new endeavour for topicmaps.org? [Lars Marius Garshol] > > * 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. > Ah, I'm starting to see. Perhaps you wouldn't apply the term "API" to what I am thinking about. I would, but let's put that aside. I'm thinking about the user interaction aspect. I'm convinced that there are many things users will commonly need to do, and should be made as easy as possible. Even if we just set the requirements for them, that would be useful. Typically, requirements development interacts with model development. Also typically, you start with requirements before modeling,and these would be a part of the overall systems requirements if we were building a system instead of a standard. Let me try to illustrate with a different example. In a windowing environment, it's very arduous to build a window from a basic API. You have to crate each feature, even though virtually all windows have them - frame, title bar, corner icons, and so on. You have to assemble them and get their relationships right, and you probably have to allocate and manage the memory, too. Now with a toolkit like Powerbuilder, you can get the whole window in one call, and it's ready to go, hooked into Windows and the Powerbuilder application framework. I'm after an analogous capability to enhance the ease of creating Topic Map end user applications. So let's work on the requirements. > I guess the way to convince me that I'm wrong would be to come up with > requirements that demonstrate that I am. > Let me look at my rough work and see it it's willing to show itself. > ... > (I think that's my longest sentence ever. Sorry about that.) > Oh, good, we're making stimulating something! 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/ _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. 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