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

[Phil Spiby]

Ed,

Thanks for the comments.

I've actually found it easier to review your comments that the document as a
whole! (Probably because I was seeing what I thought should be in the
document, instead of fully reading it!)

My only comment.
p. 60, 9.2.3.4, rule (a):
This has been changed again!
When we discussed this by e-mail I thought we agreed that specialization was
not required for renaming, and specifying a derivation, we seem to have
slipped back again on the derivation point.
I believe Ed's proposal is the correct way to go with this:
"(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."


Phil

> -----Original Message-----
> From: owner-wg11 at steptools.com 
> [mailto:owner-wg11 at steptools.com] On Behalf Of Ed Barkmeyer
> Sent: 04 April 2003 23:05
> To: SC4 WG11
> Subject: Comments on the Part 11 Ed2 28-Mar-03 draft
> 
> 
> 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.
> 
> --------------------------------------------------
> 
>