Comments on the Part 11 Ed2 28-Mar-03 draft

[Ed Barkmeyer]

Jochen et al.,

(Just when you thought it was safe to go back in the water... ;-)
Below please find my comments on the most recent draft of Part11 Ed2.
They are all 'editorial', but they became more numerous and complex than 
I expected.  If it would help, I can put them into the ISO template form.

-Ed


-- 
Edward J. Barkmeyer                       Email: edbark at nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Mail Stop 8260          Tel: +1 301-975-3528
Gaithersburg, MD 20899-8260               FAX: +1 301-975-4694

"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority."

------------------------------------------------
Editorial comments on Part 11Ed2 draft 28-Mar-03

P. 48, 9.2.1 Note 1.
This Note is misplaced; it should appear after Rule (a) of 9.2.1.1 on 
the following page.

P. 49, 9.2.1.1, paragraph following Note 2.  This discussion of OPTIONAL 
appears to be normative text, but was clearly intended to be (was 
formerly) part of Note 3.  Put it at the beginning of Note 3.

p. 57, 9.2.3, paragraph following the syntax box, last sentence:
"Following the SUBTYPE OF links leads to supertypes while following the 
SUPERTYPE OF links leads to subtypes."
There are no "SUPERTYPE OF links".  That is, the definition of SUPERTYPE 
OF is no longer defined in 9.2.3.2 to have anything to do with "links". 
  (This is probably left over from EXPRESS 1CD:1991!)  What is meant 
here is 'following the (directed) "SUBTYPE OF" edges in the reverse 
direction leads from supertypes to subtypes.'
Note also that the graph-theoretic term is "edges", or sometimes "arcs", 
not "links".

p. 58, 9.2.3.2, first paragraph.  It appears that "subtype declaration" 
should be "SUBTYPE declaration" for consistency with 9.2.3.1.  Also, for 
stylistic reasons, I would change "declaration and is implicitly ..." to
"declaration.  An entity is implicitly ...".  (There are two definitions 
here, and each should be a sentence.)

p. 60, 9.2.3.4, 2nd bullet under Example 1:
9.2.7 now says that a select over subtypes of the original entity data 
type is a specialization of that entity data type.  So this bullet seems 
to be entirely redundant -- the 2nd bullet (p.59) says you can redeclare 
to any specialization.  I would delete this bullet, but if you elect to 
keep it, then it has two problems:

p. 60, 9.2.3.4, same bullet:
"— if the original data type of the attribute is an entity data type, 
which is also a supertype, ..."
This should read "... an entity data type that is also a supertype ...".

p. 60, 9.2.3.4, same bullet:
"this select data type shall only identify either a collection of 
subtypes of the original entity data type or a specialization of those 
subtypes;"
What is meant by "a specialization of those subtypes"?  *one* 
specialization of *multiple* subtypes?

p. 60, 9.2.3.4, bullet before the Note:
"— an attribute in the supertype may be given a new identifier in the 
subtype. The new attribute identifier obeys all the scope and visibility 
rules defined in clause 10. It can be used as a true alternative to the 
original attribute identifier."
This is inaccurate.  It is not a "true alternative" to the original, and 
cannot (in general) be used in (qualified by) other subtypes of the 
supertype.  What the NOTE says about the original is exactly the scope 
of the new name.  Try:
"The new identifier obeys all the scope and visibility rules defined in 
clause 10 for an identifier for an attribute of the subtype whose 
declaration includes this redeclaration; but the identifier always 
refers to the original attribute in the supertype."

p. 60, 9.2.3.4, rule (a):
"a) An attribute that is redeclared in the subtype, but not renamed, 
shall be a specialization of the attribute in the supertype. ..."
This is mis-stated.  Specialization is a relationship between data 
types, not attributes. Try:
"a) If an attribute that is redeclared in the subtype is not renamed, 
the data type declared for the attribute in the subtype shall be a 
specialization of the data type declared for the attribute in the 
supertype. ..."

p. 61, 9.2.3.4, rule (f):
"In this case, the attribute in the subtype need not be a specialization 
of the corresponding attribute in the supertype."
This is mis-stated as in rule(a) above, and "corresponding" is wrong 
(it's the *same* attribute), but this rule is also misleading.  The 
intent here is:
"In this case, the data type declared for the attribute in the subtype 
shall be the same as, or a specialization of, the data type declared for 
the attribute in the supertype."

p. 61, 9.2.3.4, rules (a) and (f):
The last sentence of rule (f) should be moved to rule (a) -- it is those 
two rules that are a complete pair.  Rule (f) is about naming.
But it also seems that a lot of wording is spent making it invalid to 
redeclare an attribute without actually constraining its data type. 
Wouldn't it have been easier to make rule (a) simply:
"(a) the data type in the redeclaration shall be the same as, or a 
specialization of, the data type of the attribute declared in the 
supertype."
(I assume that this may have been debated and resolved; and I don't want 
to reopen the debate if that is the case.  Just put the whole rule in (a).)

p. 61, 9.2.3.4, rule (g) should be a NOTE.  It follows from 9.2.3.5.

p. 63, 9.2.3.5, first paragraph.
"Every local or global rule that applies to a supertype applies to its 
subtype(s)."
This can easily be misinterpreted.  What is meant is:
"Every local or global rule that applies to all instances of a supertype 
applies to all instances of its subtypes."
Because in global rules it is possible to make rules about the *extent* 
of an entity data type (subject of my treatises on subtype constraints), 
those rules do not apply to the subtypes in the sense that the subtype 
can be substituted for the supertype in the rule.  Local rules are 
always about instances; so that's never a problem.

p. 64, 9.2.4, second paragraph (below the box)
"It is possible to specify constraints on which subtype/supertype graphs 
may be instantiated.  These constraints are specified in the supertype 
by means of the SUPERTYPE constraint."
This is true, but it isn't the whole truth anymore, and the NOTE tells 
us that this is the lesser half.  Replace the last sentence with:
"These constraints may be specified in the declaration of the supertype 
by means of the SUPERTYPE clause.  They may also be specified as 
separate rules, by means of SUBTYPE_CONSTRAINT declarations (see 9.7)."

p. 64ff, 9.2.4 and 9.2.5, generally.
Nowhere in subclause 9.2.4 et al. does it say what a subtype_constraint 
actually means!  And it is far from obvious that it is to be interpreted 
as a set of quasi-independent constraints, which is what Annex B does! 
9.7 says that subtype_constraints are specified in 9.2.4 (and .5), but 
their meaning isn't; we should fix it here.

After the deprecation Note in 9.2.4, insert the following:

"The meaning of a subtype_constraint is the set of constraints stated in
the supertype_expression.  A subtype_constraint can contain any number 
of AND constraints and ONEOF constraints.  Each is interpreted as a 
separate constraint.

In addition, when it appears in the statement of some more complex 
constraint, each ONEOF, AND and ANDOR expression is interpreted as a set 
of instances of the supertype.  In interpreting the 
supertype_expression, the following rules apply:

- an entity data type name appearing anywhere in a supertype_expression 
is interpreted as the set of entity instances constituting the entire 
population of that data type, just as in a global rule (see 9.6);

- the result of an expression in a supertype_expression is interpreted 
as a set of instances of the supertype, as specified for ONEOF, ANDOR 
and AND below.

Although the 'final result' of the supertype_expression in the 
subtype_constraint is therefore a set of entity instances, that set has 
*no significance*.  That is, the 'result' of the whole 
supertype_expression does not state any constraint -- it does not 
necessarily include all instances of the supertype, and may include 
instances to which none of the stated constraints applies.

NOTE -- Therefore, independent constraints can be connected by ANDOR, 
which only adds instances to the (meaningless) overall result of the 
supertype_expression."

p. 64, 9.2.4, paragraph beginning "Annex B".
At the end of the next paragraph, add:
"That is, Annex B characerizes the supertype populations that satisfy 
the whole subtype_constraint."

p. 64-65, 9.2.4/9.2.5 Section numbering
There is a subclause numbering problem here.  9.2.5.2, 9.2.5.3, 9.2.5.4, 
and 9.2.5.5 state subtype constraints and are referenced as a body in 
9.7.  They should all be in 9.2.4, which is about instantiation 
constraints.  By comparison, 9.2.5.1 is about a special kind of entity 
declaration that has *weakened* constraints on the *declarations* of its 
attributes.  Recommendation:
Move 9.2.5 and 9.2.5.1 to precede what is currently 9.2.4.
(See also the following comment.)

p. 65, 9.2.5, first (only) paragraph.
The second sentence of 9.2.5 makes a ONEOF out of a SUBTYPE 
relationship, in one sense, but it also compares apples and oranges. 
Every ABSTRACT entity satisfies the ABSTRACT SUPERTYPE constraint.
But an abstract entity is a special kind of entity; while ABSTRACT 
SUPERTYPE is a constraint -- a rule.  Recommendation:

a. In 9.2.5.1, add a Note after rule (b)
"NOTE: Rule (b) implies that every abstract entity data type satisfies 
the abstract supertype constraint (see 9.2.5.2)."

b. Delete 9.2.5 and its paragraph, renumber 9.2.5.1 to 9.2.5 (3rd level 
heading).  If necessary, move the first sentence of the paragraph into 
9.2.5.1.

p. 65, 9.2.5.1, 1st paragraph and rule (b)
"An abstract entity data type may declare explicit and derived 
attributes of data type generalized_types."
generalized_types is not a data type; it's just a non-terminal.
This should read:
"An abstract entity data type may declare explicit and derived 
attributes whose data types are generalized data types (see 8.5)."

Similarly, in rule (b), replace
"all attributes of data type generalized_types"
with
"all attributes whose data types are generalized data types"

9.2.5.3, first paragraph
The first sentence is almost right; the second is at best redundant; I 
don't know what the third says; and nothing says what the ONEOF means 
when "combined with other subtype constraints" (in the sentence below 
the syntax box).  If the operands of the ONEOF are expressions instead 
of named types, the term "element" is wrong.  We need to talk about 
"populations" or "extents".

a. Replace the paragraph with:
"The ONEOF constraint states that the populations of the operands in the 
ONEOF list are mutually exclusive -- no instance of any of the 
populations of the operands in the ONEOF list shall appear in the 
population of any other operand in the ONEOF list."

b. Add the following sentence at the end of the paragraph below the box:
"When a ONEOF constraint occurs as an operand in another constraint, it 
represents the set of entity instances that is the union of the 
populations of the operands in the ONEOF list."

9.2.5.4, first paragraph
"If the subtypes are not mutually exclusive, that is, an instance of the 
supertype may be an instance of more than one of its subtypes, the 
relationship between the subtypes shall be specified using the ANDOR 
constraint."

This states the constraint backwards -- it doesn't say what ANDOR means, 
it says when to use it.  And it doesn't tell me what ANDOR means when it 
  appears inside another subtype constraint.  Replace the normative text 
with:
"ANDOR does not state a constraint -- an instance of the
population designated by the ANDOR expression may be an instance of
either operand population or both.  Within a complex constraint, the 
ANDOR represents the set of entity instances that is the union of the 
populations of the operand expressions."

9.2.5.4, Note.
"NOTE The phrase b ANDOR c reads in natural language as 'an instance 
shall consist of the types b and/or c.'"
This is false.  ANDOR does not require that an instance of the supertype 
"shall consist" of anything in particular; ANDOR is only meaningful as 
part of a more complex constraint.  Replace the note with:

"NOTE -- ANDOR is only used in constructing a 'union' of populations for 
a more complex constraint. The phrase 'b ANDOR c' means 'all instances 
of type b and all instances of type c, including any that happen to be 
instances of both'."

9.2.5.5, first paragraph
"If the supertype instances are categorized into multiple groups of 
mutually exclusive subtypes (that is, multiple ONEOF groupings) 
indicating that there is more than one way to completely categorize the 
supertype, the relationship between those groups shall be specified 
using the AND constraint. The AND constraint is only used to relate 
groupings established by other subtype/supertype constraints."

There is no relationship between what this paragraph says and what Annex 
B does with AND!  The interpretation in Annex B has nothing to do with 
ONEOF groupings, and that interpretation makes P AND Q a meaningful 
constraint when P and Q are entities.  Replace the normative text with:

"AND states the constraint that the populations specified by the two 
operands shall be identical.  That is, any instance of the left operand 
population shall also be an instance of the right operand population, 
and any instance of the right operand population shall also be an 
instance of the left operand population.

When the AND expression occurs as an operand in a complex constraint, it 
represents either of its operand populations (they are identical)."

p.88, 9.7.3.1, first paragraph, second sentence:
"The ONEOF constraint may be combined with the other supertype 
constraints to enable the writing of complex constraints."
This is not said of either AND (which is also a constraint) or ANDOR 
(which is not).  This sentence should either be omitted here (because it 
is stated in 9.2.5.3), or repeated in 9.7.3.2 and 9.7.3.3 with 
appropriate substitutions for 'ONEOF constraint' (because it is also 
true of them).  I would strike it here.

--------------------------------------------------