Xesam meta-meta-data spec needs attention.

[Mikkel Kamstrup Erlandsen]

2007/4/30, Phreedom <phreedom.stdin at gmail.com>:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070501/7a8dfb69/attachment.htm