On Friday 04 May 2007 13:00:28 Evgeny Egorochkin wrote: > On Thursday 03 May 2007 10:42:49 Mikkel Kamstrup Erlandsen wrote: > > > > > 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? > > This is an incorrect comparison. Xesam provides what would be an equivalent > of XML Schema. Regular devs only do fill-in the blanks job on a simple > template with a human-readable doc and examples. > > Nobody really have exaustive knowledge of any reasonably complex standards > just like no dev(even highly skilled) knows the libraries he's using. > > > > 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. > > > >4444 > > 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... > > .desktop doesn't allow classes for files. This can be replaced to a degree > by file:types. e.g. [compressed, lossless, audio] or [document,text,source > code] > > Missing are structures. As soon as we go further than generic metadata like > author and size, and try to extract document structure, we'll run into > troubles. An example: c++ sources with nested classes and their members. > Too many workarounds would be necessary for .desktop > > I do realise that the first revision of xesam spec is not likely to go that > far. Nevertheless, I expect to hit .desktop limitations quite soon and > don't find it reasonable to reinvent the wheel(visualisation etc). > > btw, is there any way to provide for localization in Notation-3 or Turtle > RDF? I can't seem to find any. The advantage of these syntaxes is that they
that is a very good question. I will forward that and see what our experts have to say. > are as clean as .dekstop while remaning a fully-featured RDF syntax. > It could look like this: > > @base URL > > Author > is_a field; > of_type integer; > ... > comment "example". > > > > 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 :-) > > You are doing just fine at this moment :) > > -- Evgeny > _______________________________________________ > xdg mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
