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
> > >
> > > 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
> > >
> > > 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
> > objects - as fx a mandatory uri would be. My opinion is that we
> > *force* URIs or any mandatory property onto any object.
> The intent of this was to make life easier for apps by guaranteeing
> of some basic properties, however I do agree that the list would be
> 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
> > unique string ID along side all objects. It might want to be able to
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg