Xesam meta-meta-data spec needs attention.

[Evgeny Egorochkin]

On Wednesday 02 May 2007 21:52:33 Mikkel Kamstrup Erlandsen wrote:
> > > $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.
>
> Ok, I can see the point in removing string_enum and string _enum_ext and I
> like Sebastians proposal. What is exactly the idea behind string_enum_ext
> anyway? If you can use arbitrary values outside the enumeration then what's
> the point of the enumeration?

These values are *suggested*. e.g. phone number: work, home, cell or whatever 
use choses. The user/app picks the most appropriate from the list, or puts in 
custom value. This way we get the most controlled-vocabulary benefits, while 
still providing for custom values. Another benefit is that these values can 
be translated.

> Also, why do we need to enforce that metadata matches a regexp? Wouldn't it
> be enough that the spec defined that we URI field should contain a
> qualified uri?

Sanity checks. Also strigi plans to let users/app edit metadata, so there must 
be a way to validate it. There are many fields with fixed formats like IP 
address, e-mail, ISBN etc. You are not going to add a field type for all 
this?

> Also i think it might suffice to specify numeric ranges like 1.5-3.756 and
> not use brackets as suggested - {=inclusive, <=exclusive... Just define
> that all ranges are inclusive.

Yes. the problem is you'll have to specify ranges like 
0-0.9999999999999999999 :) unless we have some way to limit float precision.