On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > Hi, > > I'm one of the main authors of BMP 2 (still being worked on), and along the > way of reworking our library, i came across the idea of encoding library > queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari"
(Is that at all a valid URI? I'm not sure.) First of all, one can't simply invent ones own URI scheme, because it causes trouble. Especially, for such a generic name as "query". This document discusses this further: http://developer.kde.org/policies/uri-guidelines.xhtml How is interoperability for "query" ensured? Is it specified? > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > playlists, XSPF, M3U, etc). > Now i thought it might be not a bad idea to create a playlist format with > these query URLs, and i've called it "MLQ" for media library query. In > theory, it's not even > application specific. The keys (identifiers), like artist, album, etc, are > all based on GStreamer tag identifiers. (They could be maybe adapted to > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but > it seems insufficient and doesn't specify certain items, like musicbrainz > metadata, which GST does). > > So i've called this file format "MLQ", with the extension .mlq, created a > mime package file for it: I think this highlights possible trouble. Anyone else who decides to invent "query" will get detected as "Media Library Query List". All that's needed to fix this is to use URIs properly. However, I wouldn't invent a new URI scheme for this, it's too context dependent. Music players & hardware(ipods, music players, music sharing sites, and so on) is quite popular in western societies right now, but next year it's something different. Technologies, such as a URI scheme, shouldn't be hard coded on a specific use, it should be generic. Re-use existing technologies. There's plenty of work and research on meta data and querying data. Here's my suggestions: Express the format in XML. This has nothing to do with XML files("text"), unless one wants to. It means the format is conceptually, on an "abstract" level, described in XML which in turn opens up the door for all methods XML has. For example, one could use an XPointer fragment with an XPath scheme: file:///myMusicColltion#xpointer(xpath1([EMAIL PROTECTED]'Milosz' and @album = 'Safari')) If "music collections" cannot be located as files, invent a scheme which can identify them on this "abstract level." However, I would first assess RDF as suggested in this thread, since it is designed exactly for things like this. In this way one doesn't have to invent a whole query language for music files. That's like inventing C++ for writing games, C++ for fixing bugs in word processors, C++ for writing editors, and so on. Cheers, Frans _______________________________________________ gnome-multimedia mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-multimedia
