Re: Config_Files proposal {long}

["Bobby D. Bryant" <bdbryant@mail.utexas.edu>]

On Sat, 29 Jun 2002 05:03:17 -0600, Bobby D. Bryant wrote:

> Finally, if I may say so without stepping on any toes, I would
> like to call attention to the curiously "flat" examples that you
> have for the Java and XML sections on your Web page, and the
> emphasis on data types rather than on semantics.

After taking my morning walk I think I can elaborate on this
usefully.

First, regarding the "flatness" of some of the examples.  Notice
that the apparent depth of the Java and XML examples arises from the
fact that you have given the path names through the Ada package
hierarchy to the Ada type definitions as "structure" in the config
file.  But if you replaced those path names with aliases and then
used those aliases in your config file, it would immediately become
apparent that in those two examples the data is just a flat list of
{type, name, value} tuples (with a huge pile of useless syntax
thrown in for the XML implementation, to boot).

Compare that to the X example, where the nesting in the config file
actually represents some structure in the data.

Sure, you *could* represent the X data as a flat list, but
presumably it is intended to be isomorphic to some nested data
structure that has nested meaning in the actual program.  In fact
Ada will let you nest record structures to an (ideally) unbounded
depth, and in practice I do find myself going several layers deep
from time to time.  And for ease of comprehension I think it
important to represent nested structures as nested structures in the
config file.

Accordingly, please consider changing -

"15. At least one layer of key hierarchy is supported."

with -

"15. At unbounded depth of key hierarchy is supported."



Also, if you want people to look at the examples on your Web page to
help them decide which syntactic system is best for the job, then I
would think that the following would be absolutely essential -

(a) Level the playing field:  Each example needs to specify
identical data.

(b) Raise the bar:  For the examples, use the most demanding example
rather than a simpler one.   (Solicit to see what people feel that
config files must support, and use that feedback to construct a
'wicked' example.)

I suspect you will find that if you level the playing field and
raise the bar, some suggested syntaxes will rule themselves out
immediately.  Also, by working with a 'wicked' example you can
ensure that we're not here revisiting the syntax question again in
2-3 years when people discover that the standard only supports the
most rudimentary data representation problems and does not actually
meet the requirements of complex programs.


Notice that I'm not commenting on the specification of data types in
the config file.  If that's necessary or desirable then it should be
done, but it should be an "also" added to the structured
representation of structured data, not an "instead of".  The key,
IMO, is to get the representation of the structured data right,
after which type-tagging should be a relatively minor detail.

When I say "structured data" I mean, minimally, support for records,
iterative structures (arrays or lists, possibly with identical
representation in the config file), 2-D tables, etc., including
unbounded nesting of structures.

later,

Bobby Bryant
Austin, Texas

p.s. - Wandering yet farther from my main point...  For arrays it
would be nice if the API had a function call that would let your
proram peek to see how long an array was in the config file,
so that you could peek, allocate the array, and then load it, with
two calls to the API and a "new" statement in between.  For lists,
there needs to be some mechanism for easily saying "OK, now give me
the next one."