Xesam meta-meta-data spec needs attention.

Mikkel Kamstrup Erlandsen mikkel.kamstrup at gmail.com
Tue May 1 21:47:42 EEST 2007


2007/5/1, Evgeny Egorochkin <phreedom.stdin at gmail.com>:
>
> On Tuesday 01 May 2007 17:55:26 Mikkel Kamstrup Erlandsen wrote:
> > > > $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.
> > > >
> > > > Is there any example of a mandatory property? Does it even make
> sense?
> > >
> > > File name or URI?
> >
> > I don't see why they have to be mandatory. Not everything comes from a
> > file.
> >
> > In the search API it is specifically avoided to use global identifiers
> for
> > objects - as fx a mandatory uri would be. My opinion is that we
> shouldn't
> > *force* URIs or any mandatory property onto any object.
>
> The intent of this was to make life easier for apps by guaranteeing
> existence
> of some basic properties, however I do agree that the list would be
> extremely
> short if not non-existent.


Also taking URI as an example, you would need to enforce that it actually
contains a valid uri or else it would be useless anyway. We could add
another type called "uri" which guarantees that the values form a valid uri.
I don't think we should guarantee that any fields are indeed set though.

 Is it always possible to derive this from
> >
> > > field type or not?
> >
> > I don't think you can derive it always. Think of some app that stores
> some
> > unique string ID along side all objects. It might want to be able to
> search
> > for these IDs, but it surely don't want them tokenized just because they
> > might contain a space. In this case the app would want to use
> > INDEXING=atomic.
>
> Reasonable. I proprose to make atomic the default.


That is probably the right thing to avoid some really wierd results by
unaware programmers.

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070501/7d42d7ea/attachment.htm 


More information about the xdg mailing list