extended attribute standardization

[Bastian, Waldo]

>> What I would like to discuss and later put in writing are actually
rather
>> simple things. I think, for instance, that it would be useful to
store
>> arrays of information in extended attributes (think of a file history
of
>> source URIs whenever a file is copied or moved). Storing an array
would
>> require some kind of encoding where each element is separated by
>> semicolons. Now there must be a way of storing semicolons in the
elements
>> themselves, so there must be an escape sequence for semicolons. This
is
>> not a very complicated concept in itself, but different people come
up
>> with different solutions (which may or may not be equally good). I
think
>> that discussing these things and writing them down will benefit
>> programmers in the future.
>
>Freedesktop hosts a page called Standards/shared-filemetadata-spec
>which defines datatypes, where one type is "Array of String (comma
>delimited list of strings)". As far as I understand it, this spec
>mainly deals with metadata that is indexed in external systems, but it
>makes sense to borrow from this spec for example the datatypes. Some
>escape mechanism should probably be added to deal with strings that
>includes commas.
>
>I also noted that the desktop entry spec sometimes refers to lists,
>but does not always  define the separator. For example for the keys
>OnlyShowIn, NotShowIn, FilePattern.

The default separator is semi-colon as described in the desktop entry
section on "Possible value types":

"Some keys can have multiple values. In such a case, the value of the
key is specified as a plural: for example, string(s). The multiple
values should be separated by a semicolon. Those keys which have several
values should have a semicolon as the trailing character. Semicolons in
these values need to be escaped using \;. "

Cheers,
Waldo
 
Intel Corporation - Channel Platform Solutions Group - Hillsboro, Oregon