[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xtm-wg] A challenge on "the graph"
* 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC