[GRASSLIST:1195] Re: [GRASS5] Re: notation standardisation

[Eric G . Miller]

As follow-up, I also think we should use the same parameter names used
by g.list, g.copy, g.remove, etc. when input/output aren't appropriate.

So we have "rast", "vect", "sites", "icon", "labels", "region", "group",
and "3dview" to use (and maybe "dspf" ?).

Rule of thumb [proposed]:

1. If the module takes a single input and produces a single output, then 
   use input=[name] and output=[name].

2. If the module just performs some action, but doesn't produce an
   output different from the input, then use the input "types" parameter
   "name" (i.e. "rast", "vect", etc...).

3. If the module has multiple inputs or outputs, then attempt to use the 
   parameter names above if possible, else parameter names are left up
   to the author.  So, If I had a module that took a raster and a vector
   and produced a raster, it's parameters could be:
   	r.something rast=[name] vect=[name] output=[name]
   However, with some modules, there's more than one input or output of
   a single "type", so then each name should be descriptive of what its
   function is.

I don't know that we ever resolved the issue of addressing sites
attributes.  Basically we have something like:

   "east", "north", "dim", "cat", "decimal", and "string";
   
for attribute names. For the "index", I don't know; maybe just "index"
when there's only one to be specified, otherwise "zindex" for "dim",
"dindex" for decimal and "sindex" for string???  I know I'm guilty of
not being consistent here.

NOTE: I'd like to get some kind of simple attribute database implemented
in GRASS, but so far I haven't found anything that we could just plug in
with a few tweaks.  The closest might be the Xbase library, but it's C++
and I don't know how well Xbase files might support efforts at
localization in the future.  Anyway, I bring this up, because
identifying attributes by "type" and "index" is really cumbersome.

-- 
Eric G. Miller <egm2 at jps.net>