On Wednesday 02 May 2007 14: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
good idea. Since my workshop pretty much failed (mostly my fault)... > 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. > > jamie. > > > Cheers, > > Sebastian > > > > On Tuesday 01 May 2007 06:56:30 Mikkel Kamstrup Erlandsen wrote: > > > 2007/4/30, Phreedom <[EMAIL PROTECTED]>: > > > > I'm writing this on behalf of Strigi project. > > > > > > > > It's important to finish Xesam specs as soon as possible since lots > > > > of code > > > > and work starts to depend on meta-meta- and meta- data spec and it > > > > gets more > > > > and more complicated to make changes. > > > > > > Thanks a ton for picking up on this. I have not been able to yet myself > > > since I have been utterly swamped in real-world chores. It will be > > > better after 5/5. > > > > > > > > > I believe Xesam metadata bainstorm wiki page has shown that proposals > > > mostly > > > > > > > split along .desktop vs RDF representation line, with the essense > > > > being very > > > > similar. So it's about time to finish meta-meta-data and start > > > > actively working on meta-data spec. > > > > > > > > Another concern is KDE feature freeze on 1th june which is also going > > > > to affect our ability to implement Xesam. > > > > > > I was wondering about that. I shall try and update the roadmap later > > > today to accomodate for this. > > > > > > > > > At the end of the e-mail is our lastest proposal for meta-meta-data > > > > > > > specification. > > > > > > > > Best wishes, > > > > Evgeny > > > > > > > > Format specification of .fieldproperties files(DRAFT) > > > > > > > > ===================================================================== > > > >==== ============= > > > > > > > > [Field] > > > > Uri=$URI > > > > ParentUri=$PARENTURI > > > > Name=$NAME > > > > Name[$LANG]=$LOCALIZED_NAME > > > > Description=$DESCRIPTION > > > > Description[$LANG]=$LOCALIZED_DESCRIPTION > > > > TypeUri=$TYPE > > > > Values=$VALUES > > > > Values[$LANG]=$LOCALIZED_VALUES > > > > Range=$RANGE > > > > MinCardinality=$MIN_CARDINALITY > > > > MaxCardinality=$MAX_CARDINALITY > > > > Indexing=$INDEXING > > > > Relevance=$RELEVANCE > > > > Comment=$COMMENT > > > > > > > > $URI(required) > > > > Unique resource identifier of the property. Internally properties > > > > are identified by this ID. > > > > Alternative to this would be [$URI] instead of [Field]. > > > > > > I would go for the alternative since we need this to be able to have > > > multiple field defs in one file. This is because the format spec for > > > .desktop files requires that group headers are unique. I know we can't > > > follow the .desktop spec to the letter but we might as well aim as > > > close as possible. > > > > > > $PARENTURI > > > > > > > URI of parent property. Parent relation is similar to inheritance. > > > > Usually > > > > child property > > > > introduces some specifics/limitations/implications compared to its > > > > parent. > > > > > > > > $NAME(required), $LOCALIZED NAME > > > > Short user-friendly name. This is the name users will see when file > > > > metadata > > > > is displayed to them. > > > > > > > > $DESCRIPTION(required), $LOCALIZED_DESCRIPTION > > > > User-friendly property description. This is the description of > > > > property suitable for tooltips. > > > > > > > > $TYPE(required) > > > > Property data type. > > > > Valid values: string, string_enum, string_enum_ext, integer, float, > > > > boolean, > > > > datetime, binary. > > > > string_enum type is a property that can only take one of the list > > > > of valid > > > > values provided by $VALUES. > > > > string_enum_ext type is a property that can take any string value, > > > > however > > > > $values list provides > > > > suggested values of this property. > > > > > > > > $VALUES(required if $TYPE=string_enum or string_enum_ext), > > > > $LOCALIZED_VALUES > > > > Property value constraints. Default = no constraints. > > > > if $TYPE=integer|datetime|float, $VALUES=value1|value2|value3 > > > > if $TYPE=string, $VALUES=validation regexp > > > > if $TYPE=string_enum, $VALUES=value1|value2|value3 > > > > if $TYPE=string_enum_ext, $VALUES=value1|value2|value3|*(or) > > > > This syntax lets us directly use $VALUES as a regexp for validating > > > > user input. Yet it's syntax > > > > is developer- and translator- friendly. > > > > Suggestions on regex subset are welcome. KDE and Strigi is going to > > > > use QValidator and QRegExp for this. > > > > > > > > $RANGE > > > > Numeric property allowed value range. Default = no constraints. > > > > $RANGE=[minValue,maxValue> > > > > [ and ] = inclusive. < and > = exclusive. > > > > > > Can you mix the braces like [0,1>. I'm not 100% sure this syntax is > > > possible with a .desktop like spec. I'm mostly worried about the ['s > > > also used for group headers. > > > > > > > > > $MIN_CARDINALITY > > > > > > > Minimum cardinality. Minimum number of properties of this type you > > > > must set > > > > for a given file. > > > > Lets specify mandatory properties. Default is 0. > > > > > > Is there any example of a mandatory property? Does it even make sense? > > > > > > > > > $MAX_CARDINALITY > > > > > > > Maximum cardinality. Maximum number of properties of this type you > > > > can set > > > > for a given file. > > > > Default is infinity. > > > > > > > > $INDEXING > > > > Values=fulltext, atomic, none, TBD. Default = TBD. > > > > > > Can you please describe what these values mean? I think I get it, but > > > let's be sure :-) > > > > > > > > > $RELEVANCE > > > > > > > Defines how relevance of the file is affected if a match is found > > > > in this > > > > field. Default = 1.0 > > > > > > > > $COMMENT > > > > Developer comment. Users won't see this. > > > > > > Overall I agree. The biggest issue is the group header as I comment > > > above. > > > > > > Thanks again for picking up on this! Cheers, > > > > > > Mikkel > > > > _______________________________________________ > > xdg mailing list > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/xdg _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
