[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xtm-wg] A challenge on "the graph"
* Lars Marius Garshol | | Does this mean 'strawman' is nice, tables better, and that the best | of all would be a clear graph model? If so, how do you think a graph | model is better than an infoset-based approach? So far, nobody has | said anything in answer to that last question. * Nikita Ogievetsky | | I guess because nobody understands benefits of it. | (May be you can point them out?) Nikita, I don't think there _are_ any benefits to the graph model. That's why I am participating in this discussion. As for nobody seeing the benefits of the graph model and therefore being unable to point them out, that is beginning to seem very likely. Taking the step from there to concluding that it is the wrong approach seems to be a very hard thing to do, though. | With regards to graph notation, | I know that it can be done, Of course it can! But I do think the result will be harder to comprehend. | it will be visually comprehensible, If it is, it will be no less so than the infoset-based approach, where items become nodes and properties that have other items as their type become edges. | and as Jean pointed out, it has been proven successful. By what? | Plus we will create a bridge to RDF. I think that is a separate goal. I believe that what we need now is to specify topic maps in sufficient detail for implementors (and those who want to judge the efforts of implementors) and in such a way that it becomes possible to clearly decide whether an implementation follows the specification or not, and thus also to make interoperability of topic map processors a real possibility. Steven Newcomb has accused the current XTM 1.0 specification of not specifying processing with sufficient formality, and that is an accusation that I wholeheartedly agree with. In fact, this has been my position since the autumn of last year and little has happened to the spec to change that. (Annex F is not enough, since it is not model-based, whether that model be graph-based or something else.) If the purpose of the processing model is _not_ to support implementors and help them get their implementations right, or if it is that _and_ something else, I would be very glad to be told what those other goals are, and for them to go into the list of requirements. --Lars M. ------------------------ Yahoo! Groups Sponsor ---------------------~-~> Secure your servers with 128-bit SSL encryption! Grab your copy of VeriSign's FREE Guide, "Securing Your Web site for Business." Get it now! http://us.click.yahoo.com/4cW4jC/e.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