Xesam meta-meta-data spec needs attention.

[Evgeny Egorochkin]

On Wednesday 02 May 2007 15:26:14 Sebastian Trüg wrote:
> > $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.
>
> How about using xml schema types here. That way a later mapping to RDF will
> be easy and Nepomuk can stay compatible without an artificial mapping. The
> only problem here are the enumerations. XML Schema does support creating
> enumerations but I think they are complex types. How about this: the type
> will stay a string or an int or whatever. But if the VALUES field is set it
> is to be treated as an enumeration. I don't think we need the extra types
> here.

You can have a string type instead of 3: string, string_enum, string_enum_ext. 
This information is in fact redunant. This was done only to improve 
readability.

> > $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.
>
> Actually there is no need to have RANGE and VALUES. Just merge them into
> range:
> RANGE=1,4,5,2.3
> RANGE=1-7
> RANGE=hello,bello,wello

The idea behind values= was to:
1) allow regexps
2) seamlessly integrate enumerations into these regexps
3) have a compact, clean format for this.

> > $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.
> >
> > $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.
>
> what is this supposed to do?

Was explained in my correspondence with Mikkel:

So fulltext is text that should be tokenized, filtered for stop words,
stemmed, and indexed, right?

Atomics should be indexed as one searchable chunk. No stemming, splitting,
filtering. Just stick it in the index..

None is self-explanatory.
Yes - don't index this field. But I take it you can still retrieve the value
of it... Or else there is no reason defining the field in the first place...