Xesam meta-meta-data spec needs attention.

[Mikkel Kamstrup Erlandsen]

2007/5/2, Evgeny Egorochkin <phreedom.stdin at gmail.com>:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070502/d558957c/attachment.htm