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