OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[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