[Tfug] Stored settings

[Bexley Hall]

Hi, Rob,

> As programmers we often choose to use meaningful
> identifiers in our code so that the intent of our
> endeavors are obvious to human readers.

Well, one could argue that point... :>

> Based on this principle, you may argue that data should be
> human readable, as well.  However, if you think about it, the
> only thing that is human readable (whether we are talking about
> source code, image data, a configuration file, a relational
> databases, etc.) is what pops up on our display.

Exactly.

> The process of translating these internal data representations
> to one that you (a human) can understand
> is well defined within a specific context.

But, that's the whole point.  I, as the developer, can elect to
map a set of enums to a set of "interpretations".  I, also, as
the developer, can elect how I present those enums to the user
as he/she peruses the "settings" in effect.

If you just let the user see raw data from (whatever) database
or configuration file, then he *must* have something to assist in
interpreting those raw values.

OTOH, if you present them to him in a manner that he is likely
to grok (given some understanding of the application itself),
then you eliminate that need for "supporting documentation".

> My point is that data representation and the meaning of
> said data are two separate and equally necessary components
> of an information vector.

Yes.  My point is wrapping that "interpretive" information around
the "raw" data prior to presenting it to the user.

E.g., when you are *using* an application (e.g., an address book),
you understand "sort by {last name, first name, phone number,
zip code, state, city, etc.}".  So, if you were examining the
configuration settings for said application IN THE ABSENCE OF THE
APPLICATION ITSELF, you would be more likely to understand:

sortby = ZIP

than:

sortby = 4

> For example, if I gave you 32 random bits, and asked you what
> they represented, then you would probably be hard pressed
> to say exactly what, unless I gave a specific context (e.g., a
> two's complement integer, an IEEE single precision floating
> point, etc.), *and* you were familiar with the specification
> of these data types.

Of course.  And, since the issues I am addressing are typically
NOT covered by any such existing Standards, you're SOL.

> And even if you decide to use English words for things such
> as settings in a configuration file (e.g.,
> EraseBootDriveOnPowerUp =
> Never), inherent complexities (such as the ambiguity of natural
> language), or introduced complexities (such as functional
> drift of a program) could also cause confusion.  "What do you
> mean "Never"? Never except when in Top Secret mode?  Never on
> Sunday?  Which "boot" drive?  I have three of them!

That goes to my comment of "understanding the application".
I.e., you could argue that my sortby example is ambiguous as
perhaps it is intended to apply to the BUSINESS address associated
with each address book entry, etc. (instead of the "home" address).

But, there's a point where you have to assume the user is familiar
with the data he is examining.  I.e., to be pedantic, you could
recursively define each word used in your explanation of the datum
(i.e. is "address" a machine memory address at which the datum is
being stored?  or, an IP address?  or a street address?  etc.)

> Ultimately, you should use whatever data representation
> makes sense
> for your application, *and* the meaning of the data should
> be unambiguous.

Yes, but, that still assumes a mapping from "internal representation"
to "user recognizable representation" is available and useful.
E.g., I could express numeric values using Gray code...

> Minimally, you should have a formal specification of the
> data format, and, ideally, a robust set of tools for
> performing IO, validating, and transforming your data.

Exactly!  That is the point of the question.  If I bundle ALL of
these issues together in the interface *to* the "config database",
then I achieve all of the goals in a manner that is maintainable
and far more usable (to the end user) than the traditional approach
of keeping them all as separate -- though logically linked -- entities.
I.e., having a specification is only meaningful if the user has
access to it, if it is written in a form the user can easily
parse, *and* if it is kept in lock-step with the actual implementation!
If any of these get out of sync, then they are worse than useless
as they will only ADD to the user's confusion.

> This is one of the reasons I
> increasingly use XML in my own work, but I only mention XML
> as an example, and not as an exclusive, or even ideal solution.

I'm looking for a more "integrated" approach.  So the user doesn't
have to go looking for an explanation "elsewhere" (i.e., using
another tool)

Thx,
--don