[help-gengetopt]xml?

[Scott Haug]

As I started using gengetopt, I couldn't help but think that its utility could
be increased severalfold with a richer syntax.  I realize that making the ggo
syntax as easy as possible is (or at least should be) one of its goals, but
expanding on it would allow for a much richer variety of command-line option
parsings.  

One way to accomplish this would be to use xml to describe the options.  I
would imagine the sample from the gengetopt web page would look something
like this:

<options package="sample1" version="0.1">
  <option long="str-opt"   short="s" type=string required=no  />
  <option long="int-opt"   short="i" type=int    required=yes />
  <option long="funct-opt" short="F"                          />
  <option long="flag-opt"  short="x" type=flag   default=off  />
</options>

With that kind of syntax, you could easily add quite a few new features without
too much trouble.  For example, you could have the tags <short-description>
and <long-description> that could be used when displaying a full --help.  For
example, the app 'cp' might have the following tags (if it used ggo):

  <short-description>
    Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.
  </short-description>
  <long-description>
    By default, sparse SOURCE files are detected by a crude heuristic and the
    corresponding DEST file is made sparse as well.  That is the behavior

    [rest deleted]

  </long-description>

One could include the information that would otherwise only be available when
running ggo from the command-line:

  <options unnamed-opts=yes long-help=yes ... >

And by careful use of xml, you could somewhat future-proof the syntax against
later revisions, so that if an older (but still xml-enabled) ggo encountered a
later syntax, it could just ignore the elements and attributes it didn't
recognize to still produce some meaningful output.

The possibilities really do increase quickly.  One could easily see how
handling options that only have long id's (or only have short id's) would be
possible.  Aliasing one option to represent one or more other options wouldn't
be too hard, either.

Obviously, the biggest issue is the parsing code.  If this seemed like a
reasonable approach others wanted to take with this app, most (if not all) of
the current parsing code would need to be scrapped.  It would probably be best
to use an outside xml parsing lib to do this.  I would be happy to contribute
as much as possible in this endeavor.  But this seems like a pretty major
overhaul, so I can understand if no one else is interested.

If this seems like something others would want to at least look into, I could
draw up a rough draft of a DTD within the next couple days.  If not, I won't
bother.  This seems like a big enough change to the code that if no one else
thinks it's a good idea, I won't push the issue.

Thanks for listening.  Let me know what you think.

-Scott
--