PR# 13901 ECF: notation inconsistencies and lack of documentation

Problem Report Summary
Submitter: ericbe
Category: Other
Priority: Medium
Date: 2008/01/21
Class: Documentation
Severity: Serious
Number: 13901
Release: 6.2
Confidential: No
Status: Open
Responsible:
Environment: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648)
Synopsis: ECF: notation inconsistencies and lack of documentation

Description
I had a look at:

   http://www.eiffel.com/developers/xml/configuration-1-3-0.xsd

and I have a few remarks.

As in Eiffel, the attribute and element names in ECF are in
singular. So I wonder why some are still in plural, for
example: assertions.

Likewise for verbs, with no s except for some of them, for
example: extends, uses, overrides.

I would be nice if all these could be consistent.

Also, as another inconsistency, some options are specified with
an attribute of <option>, and some others as an element. I understand
that those which have too many information to be specified need to
be represented as elements. So for consistency shouldn't all be
represented as elements?

I already complained about that, but I still find the option name
"full_class_checking" confusing. When not set, does it mean that
only a few validity rules are checked? Which ones? As far as I can
tell, the notion of flat version of a class is well defined in Eiffel,
so "flat_degree_3" seems a better name for me. At the very least,
I would prefer "flat_class_checking" than "full_class_checking".

We often hear that using an XML syntax is great because the notation
is self-documented. Well, I nevertheless find it hard to use ECF
with no proper documentation. For example, even if we know what are
the possible options, we don't know what they are for (we have to
guess from their names, which is not always obvious as shown above)
and we don't know what their default values are. This document:

  http://dev.eiffel.com/Configuration

is a good start, but it is missing a section about options. Something
like what is done for settings. We also need a description of what
is the meaning of these options when applied on the different groups
or targets, and how they are combined or override each others. Likewise
for settings, how do they combine or override each others when extending
a target or using a library? I also didn't understand what the element
"uses" in <cluster> is for. There are probably others like that which
beg for documentation.
To Reproduce

										
Problem Report Interactions