"Semantic" shell? (for lack of better name)

Hi all,

I'd like to work on a method to search for packages based off of
recognized input file formats and recognized output file formats of
the contained program(s). Maybe by MIME-type (RFC 2046), such as:

image/gif
image/jpeg
image/png
image/tiff
video/mp4
video/mpeg
application/x-latex

Here's the list of MIME-type assignments:
http://www.iana.org/assignments/media-types/

However, I am by no means permanently attached to MIME. It would also
be interesting to revise the typical --help message with some
standardized markup for formally specifying which parameters would
prefer what type of information. Typically, when I write my quick
scripts, I just do a few print statements and spit out some text for
help messages, and sometimes clean it up a bit, so to replace that
laziness I'd have to write a tool to make that less of a pain, maybe
throw it in next to autoproject or something.

So, this might just mean an extra file in a package, with two lines,
the first one for input recognized, the second one for types of
output, but this of course isn't a good map for what each parameter
will trigger in terms of output, esp. in programs that change output
dependent on what it discovers about the input. Also, this only really
works for single-program packages, otherwise this needs to be done at
some other level, i.e. a file next to each binary? Is that where this
should go??

Personally this seems kind of an obvious thing to do, but it hasn't
happened yet, so I'm posting to ask specifically--

(1) Has this been proposed before? Can anyone give me names, links,
addresses, or what went wrong?

(2) Anything better than MIME for these purposes?

(3) Search terms other than 'semantic shell', anyone?

(4) What should I be asking?

I've basically written up this email on a site as well-
http://heybryan.org/shell.html

Happy new year,

- Bryan
1 512 203 0507


--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Hello Bryan,
I've thought about similar efforts, much were centered about having a
generic "command line syntax definition language".
Not every application can be squeezed into the input, output scheme. The
situation with multiple inputs, single output is common.
Neither can every application convert every input to every output,
sometimes just particular combinations might be possible (in particular,
input format might have to be the same as the output format).
Then there are "meta formats", especially compression.
For example gzip will convert any file type to the same file type but
gzip-compressed (or the other way round using gunzip).
So a tool trying to "magically" build chains would need to understand
that while gzip can process the "*/*" mime type, it won't convert the
file type, whereas 'convert' can convert next to any image file type to
next to any other image file type.
But for example to convert text/plain to image/gif with convert, you
should also specify a font...

The debtags efforts do a very minimal approach here: they use 'looser'
file types than MIME and they do not differentiate between input, output
or whatever-put. There are some benefits from that, including
- less information needs to be collected and updated
- the information is more likely to be accurate
obviously at the cost of the information being less useful. At some
point you need to make a cut.

At some point I was considering to actually use RDF-like triplets such
as "app1 reads image/gif" "app1 writes image/jpeg" etc. but we ended up
to going a tuplet-only approach for complexity reasons.

Of course things have made progress since. For example, the .desktop
files usually include useful information about which MIME types an
application supports (unfortunately, many non-GUI-application still do
not ship with .desktop files), but the information there also has some
kind of "vagueness".

So it might well be time to do the next step and collect such meta
information on a "reads" "writes" "displays" "prints" and whatever
basis. However collecting all this data sounds like a huge task to me.

I mentioned before that I was also thinking about a "command line syntax
definition language". The reason is that command line programs vary a
lot in how parameters are passed. There are certain common standards
such as GNU getopt command line syntax (i.e. single letter options with
a single dash, long options with a double dash, single letter options
can be joined ...), but there are also tons of exceptions
(e.g. "java -version" is different from "java -v -e -r -s -i -o -n" and
would have been "java --version" in getopt style).
A specification of the available options in some meta format ideally
would also give an indication of valid file types for file name
parameters. But also note about mutually exclusive options. And it is
obvious that not all command line can be described this way completely
(e.g. to fully validate "perl -e 'perl expression'" you'd need to be
able to validate perl syntax ... and "only perl can parse perl". So
you'll never know what MIME types that statement accepts ...)
A solution covering 90% might still be very nice to have.
I believe that a "semantic shell" might need to be based around the
command line interface of the applications.

best regards,
Erich Schubert
--
erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_
Reality continues to ruin my life --- Calvin //\
Der Anfang aller Erkenntnis ist das Staunen. --- Aristoteles V_/_


--
To UNSUBSCRIBE, email to debian-devel-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org