Bruce asks:

>  PS. Suppose that the QCTerm format had to start holding multi-level
>  structured data -- for example, a selection of color schemes. How would
>  the format have to be modified to accomodate this?

We're actually doing that already. The telnet address "phonebook", in all of
the versions of QCTerm that have been released, has been a five-level
encoding, such that each of the addresses below could appear in any order,
with any number of items appearing in-between the various entries:

                          TelNetAddr1 = 192.168.1.1
                          TelNetAddr2 = 209.181.113.217
                          TelNetAddr3 =
                          TelNetAddr4 =
                          TelNetAddr5 =

(I previously deleted the other entries in the TelnetAddr phonebook because
they contained IP addresses of people who were allowing us use of their
HP3000s, including you, Bruce :-).

In the newest version of QCTerm, that phonebook has been increased to 30
IP/domain addresses, in a fully compatible-with-all-prior-releases manner (I
love it!). A similar 30-name phonebook has just been put in for modem dial-up
numbers. The entries could have been just as similarly the various attributes
of a 30-color color scheme.

To make QCTerm as robust as possible, when QCTerm first loads, every
user-settable value that we allow is assigned a default value. Only after
that's been done is the configuration file is read. For each tag that the
reader routine finds, it overwrites the corresponding default data with the
configuration-specified choice. If the tag doesn't exist in the configuration
file, the default value stands.

If the configuration file doesn't exist at all, it's built at that point and
the default values are written into it. By doing it this way, QCTerm will
always come up and be ready to do something at least semi-intelligent.



> The fact that XML isn't suitable for the task of holding simple private
>  configuration files doesn't really have anything to do with its long-term
>  acceptance.

Actually, that strikes to the core of my comment. In the end, I'm not sure
that every application (and every application programmer) wouldn't be better
off using a simple, directly applicable-to-the-specific-application(s) file
format.

If XML is there only to allow each individual user or group of users to
define a highly specialized content format, why bother with doing anything
more elaborate than the above?

Wirt Atmar