2007/5/2, Evgeny Egorochkin <[EMAIL PROTECTED]>:
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.
I don't think we should allow *all* simple types from xml schema (for
example the duration type seems out of place). So string, boolean, double,
date - which maps to the obvious counterparts (date maps to dateTime).
> $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?
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?
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.
Cheers,
Mikkel
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
