2007/5/2, Evgeny Egorochkin <<a href="mailto:phreedom.stdin@gmail.com">phreedom.stdin@gmail.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote><div> 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).  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> > $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.</blockquote><div> 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? </div> 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 </div>