2007/5/2, Evgeny Egorochkin <[EMAIL PROTECTED]>:
On Wednesday 02 May 2007 21:59:15 Mikkel Kamstrup Erlandsen wrote: > 2007/5/2, Evgeny Egorochkin <[EMAIL PROTECTED]>: > > On Wednesday 02 May 2007 15:46:15 jamie wrote: > > > On Wed, 2007-05-02 at 14:13 +0200, Sebastian Trüg wrote: > > > > Hmm, so now you ignore RDF? > > > > Don't get me wrong, it is your project, so in the end it is your > > > > decision. I am just a little confused why we have this wiki page > > > > then. > > : > > :) > > : > > > Im too busy (until mid-may) to comment on the spec in much detail > > > > > > perhaps we can arrange an online discussion mid may to flesh this all > > > out > > > > > > I have a few concerns with the nature of the proposed desktop file > > > spec. > > > > > > I agree its important the desktop file should be easily convertible to > > > rdf but we do want to eliminate the complexity (and extra overhead of > > > rdf) as much as possible from it - that is the point of having the > > > desktop file. > > > > I think still this compexity issue is not an issue at all. The reason I > > think > > so is: > > 1) most of metametadata definitions will be provided by Xesam > > 2) code to parse this in the database will be written only once > > 3) If a dev needs an exotic field, somebody can help. It's not much of > > work. > > Don't underestimate where newcomer devs poke around. I clearly remember > myself a good while back poking around with some fancy gnome-vfs code, some > objects read as .desktop files, and even if I didn't know anything about > those at that time I could readily work with them. Who knows - if that had > been some obscure format (sorry I don't mean that rdf is obscure :-)) I > might have stopped there and might not have been here today... > > So even if most apps will use a helper lib don't forget that we should also > make it easy for people to poke around. Didn't we all start that way? There are RDF formats that are extremely newcomer-friendly. Nobody today complains when they see XML which looks no way better and nobody raises any "complexity" issues whenever XML is suggested as a representation. I don't see how RDF is worse in this aspect. Its representation is text-based and meta-meta spec except regexps can be figured out from just a couple example definitions. Newcomers are not dumb by any means.
Oh, I for sure complain about complex XML formats and believe me, many do. Take for instance XML Schema (just for one) do you know and appreciate the *full* spec?
So what is more important is flexibility, extensibility and compatibility. > > > Don't the .desktop-approach have that? Flexibility, no. There are many things which RDF and XML can do and .desktop can't.
Yes, of course RDF can do a lot more that is the whole point :-) But can it do anything we need that we cannot do with .desktop files? I think it would be good to have some concrete cases of .desktop vs RDF approach (with different RDF syntaxes possibly). Also it would be useful to track down some concrete cases of what RDF could do that .desktop can't... Extensibility follows from flexibility. RDF has nice extras which we may
want to use in the future. Compatibility. Do you have a tool to visualize ontology built using .desktop files? Do you have GUI editors?
It should be pretty easy to write a tool to visualize the structure of the current proposal. GUI editors - if you mean syntax highlighting then yes. It might seem far-fetched, but it isn't so. The ontology is likely to
contain ~100 fields. No less. And will grow. Maintaining it, and especially child/parent field relation gets really complex. I can feel it myself already being responsible for Strigi ontology. It is also useful for other devs in deciding which fields to use and understanding the consequences and implications. Visualization is a great help here, including those newcomers whom it'd help to grasp the ontology.
Visualization could be a great help, yes. I could write a tool for that in an afternoon with Python and Cairo. It could do well in the xesam-tools package I'm writing atm. GUI editor is also a plus. I'm sure the spec will be getting more and more
elaborate with more features added. Having some editor for all this mess is really handy, newcomers included. > Also, it is important to act fast, otherwise the goal of compatibility is > > > unattainable since much of the code gets written around metadata spec. > > Analyzers are written to extract data and feed in to the indexer in a > > specific > > format. It becomes a real problem if our projects do this in a different > > way. > > 100% right. This is a problem that is hard to address. The only solution is > just to not despair and just keep the train rolling, panic solutions are > deemed to end up disastrous at some point. I'm not offering a "panic" solution. Still such delays like till 14th and the preceding silence really bothers me and Strigi devs in general.
Sorry, I didn't mean to say that you offered a panic solution. I just meant that we shouldn't rush things through... There's already pressure to have something well-defined. You can extract
meta-data from files just fine, but in what form to feed it to the index? I can only guess at this moment and if I guess wrong it means some dev has to spend considerable time doing corrections. By 14th I expect a significant drag on Strigi due to complete absense of the standard. Also, I don't think project leaders absolutely must get directly involved. They can delegate technical negotiations to their team members and only look at "snapshots" of the negotiations & provide feedback on key issues.
Right. So project leaders, please consider sending stand-ins if you are caught in a tight spot. I just wonder - who am I gonna send :-) Cheers, Mikkel
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
