About mimetypes and action definitions

[Christophe Fergeau]

Ilmari Heikkinen a écrit :

>
> Capability descriptions being type metadata that says what the type 
> can do; e.g. ogg is sound, sound is temporal, ogg is lossy, ogg 
> supports the following bitrates...
> All this in some standard programmatically parseable format.


ogg isn't sound, ogg isn't lossy, ogg doesn't "support" a bitrate, ... 
ogg is a container format, which can contain audio streams encoded using 
vorbis, or speex, or flac, or whatever you want. But it can also contain 
video streams, and probably other kind of streams (like xml streams 
conveying additional information). mime types aren't really flexible 
enough to describe the content of a multimedia container (like ogg or 
avi) which can contain several video or audio streams encoded in 
different formats.

Cheers,

Christophe

>
> This since I'm (re)writing a converter tool that plugs existing tools 
> together and need to write capability descriptions[1] for the 
> reasoning algo. So I thought "Hey, these might be of use to other 
> people aswell, can't hurt to ask, right?"
>
> The descriptions could also be used for e.g. finding types that fit 
> into some criteria ("video types that are recommended for web") and 
> for creating type documentation.
>
>
> 2) Related to the above, I've been following the mime actions 
> discussions with some interest, since "How do I open a file that has 
> type foo?" is a subset of the more general "How do I represent foo as 
> bar?"
>
> The answers can be represented relation triplets that represent 
> type-program-type relations (what types a program can read and what it 
> can turn them into): "audio/x-wav --lame-> audio/x-mp3", or  
> "image/png --gqview-> view", or "image/png --gimp-> edit". Again, this 
> is what I need to do (and have done[2]) for the converter to describe 
> what a program can do, so maybe these can be shared aswell.
>
>
> 3) And finally, command descriptions. Machine-readable man pages, if 
> you will. Can be used to auto-build interfaces, generate 
> documentation, or (what I'm doing) plug programs together into 
> parametrized pipelines ("text into 128kbps mp3") by abstracting the 
> interface into a keyword parser ("high quality" means -q 0 for lame, 
> -q 10 for oggenc, and -quality=100 for pnmtojpeg.)[3]
>
> The command descriptions (can) also include the package name that 
> installs the command (these should probably be lists of 
> package:distro=pkgname unless all distros standardize to same package 
> names or move to 0install ;-)). Am using those to automatically 
> install the package if needed.
>
> Is there interest in a command description spec such as this?
>
>
> I need to write all three things above anyhow, but if these sound 
> useful to other people, let me know. Some easy to see possibilities: 
> context menus with "convert to"- and "view/open/edit in"-items, expert 
> system for learning about fileformats, synonym-searchable command help.
>
>
> References:
>
> These are the what the current version is, considering moving to RDF 
> import and export with YAML as the human-readable format in version 2.
>
> [1] http://conversio.sourceforge.net/ccp-1.6.3/types/image-types.xml
> [2] http://conversio.sourceforge.net/ccp-1.6.3/fml/ghostscript.xml
> [3] http://conversio.sourceforge.net/ccp-1.6.3/fml/lame.xml
>
>
>
> Ilmari Heikkinen <irkheikk cs helsinki fi>
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg