Comments on the Part 11 Ed2 28-Mar-03 draft
Jochen Haenisch
Jochen.Haenisch at epmtech.jotne.com
Thu May 29 11:53:53 EDT 2003
Hi folks,
attached is a version of P11e2 that takes comments into account from Ed and
Phil (one document is with, the other one without change marks).
In the text below, please, find the descriptions of the editorial actions
that I took on Ed's suggestions. They start with 'JH: '. I hope you agree to
them.
Attached is another log-file for Phil's comments, also relating to the
latest e-mail discussions on annex G.
I suggest to revert a part of the get-it-done procedure from my previous
mail:
1) Phil reviews my changes based on his first review comments and
potentially signs off and returns the project leader checklist to me.
2) Peter processes the document source to bring in the Kanji characters.
3) Jochen forwards the document and the Darla's and Phil's checklists and
the issues log to Dave for convenor signoff.
Using this sequence we reduce the number of times Peter needs to get into
the loop.
Dave, could you already now have a look at the document and return to me
with early change requests?
Dave, we do not use Acrobat, but a Latex pdf-tool. I hope ISO likes it.
Best regards, Jochen.
<<readme_P11e2.txt>> <<part11ed2.zip>>
<<part11ed2_with_change_marks.zip>>
> -----Original Message-----
> From: Phil Spiby [SMTP:Phil.Spiby at eurostep.com]
> Sent: 5. april 2003 19:15
> To: edbark at nist.gov; 'SC4 WG11'
> Subject: RE: Comments on the Part 11 Ed2 28-Mar-03 draft
>
> 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."
>
> JH: Suggestion adopted. 2003-05-23
>
>
> 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.
>
> JH: Suggestion adopted. 2003-05-24
>
> >
> > 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.
>
> JH: Suggestion adopted. 2003-05-24
>
> >
> > 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".
>
> JH: Text amended correspondingly. 2003-05-24
>
> >
> > 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.)
>
> JH: Suggestions adopted. 2003-05-24
>
> >
> > 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:
>
> JH: This second bullet in Example 1 removed. (2003-05-23)
>
> >
> > 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."
>
> JH: Suggestion adopted. 2003-05-23
>
> >
> > 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. ..."
>
> JH: Suggestion not adopted as specialization now optional; see below.
> 2003-05-23
>
> >
> > 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."
>
> JH: Suggestion not adopted as specialization anyway now optional; see
> below. 2003-05-23
>
> >
> > 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).)
>
> JH: Suggestion adopted that specialization is optional. 2003-05-23
> Introductory text correspondingly changed.
>
> >
> > p. 61, 9.2.3.4, rule (g) should be a NOTE. It follows from 9.2.3.5.
>
> JH: Suggestion adopted. 2003-05-23
>
> >
> > 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.
>
> JH: Suggestion adopted. 2003-05-24
>
> >
> > 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)."
>
> JH: Suggestion adopted. 2003-05-24
>
> >
> > 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."
>
> JH: Suggestion adopted - although I am not sure what this disclaimer
> means!? 2003-05-24
>
> >
> > 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."
>
> JH: Suggestion adopted. 2003-05-24
>
> >
> > 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.)
>
> JH: Suggestion adopted. 2003-05-24
> New structure:
> 9.2 Entity declaration
> ...
> 9.2.3 Subtypes and supertypes
> 9.2.4 Abstract entity data type
> 9.2.5 Subtype/supertype constraints
> 9.2.5.1 Abstract supertypes
> 9.2.5.2 ONEOF
> ...
>
> >
> > 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)."
>
> JH: Suggestion adopted. 2003-05-24
>
> >
> > 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.
>
> JH: Suggestion adopted; first sentence moved. 2003-05-24
>
> >
> > 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)."
>
> JH: Suggestion adopted. 2003-05-24
>
> >
> > Similarly, in rule (b), replace
> > "all attributes of data type generalized_types"
> > with
> > "all attributes whose data types are generalized data types"
>
> JH: Suggestion adopted. 2003-05-24
>
> >
> > 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."
>
> JH: Suggestion adopted. 2003-05-24
>
> >
> > 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."
>
> JH: Suggestion adopted. 2003-05-24
>
> >
> > 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."
>
> JH: Suggestion adopted, but text slightly changed. 2003-05-24
>
> >
> > 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'."
>
> JH: Suggestion adopted. 2003-05-24
>
> >
> > 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)."
>
> JH: Suggestion adopted. 2003-05-24
>
> >
> > 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.
>
> JH: Last suggestion adopted, i.e., sentence removed. 2003-05-24
>
> >
> > --------------------------------------------------
> >
> >
-------------- next part --------------
readme.txt
JH, 2003-05-29
1) To be done:
- replace wrong inverse figure from Peter: OK
- include Ed's comments: OK
- check e-mails for required updates
> mapping of comments: only tagged ones survive: OK (see below)
> ... I had just got to the bullet points under G.2 where it states that this
information may be lost. The bullet needs changing to reflect the current
situation regarding the generation of these global rules: OK
- update according to Phil's comments:
> remark tag: no white space allowed
> type labels for generalized attribute types in AEs
> no idea how to remove the trailing line in table 9
> rule ids in remark tags
> subtype_constraints visibility relocated to be alphabetical
> type labels in entities: their scope is limited to the entity, I suppose
> interfacing for BASED_ON: no select items at all are interfaced!
> table 17 as table 9
> example in 15.12 corrected
> annex B: "We could make this a little more interesting and exemplify
the total_over ..." - if you give me the example, Phil,
I will include it.
> annex G: tagged comments - OK
* introductory text and all copy/delete instructions
updated to include tagged remarks in the artefact longform.
Same for step 2 of the process.
> annex G: first/second class entities - OK
* removed in intro that the process discards how things are
interfaced;
* replaced the global rule dependent_x by another global rule
and a function.
> index: subtype constraint E-G - OK
> index: abstract supertype - OK
> index: abstract entity E-G - OK
> index: abstract entity - OK
> index: dotfill/hyperpage - to be edited in part11idx.tex after
final genindex; OK
- official issues resolution list: TBD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part11ed2.zip
Type: application/octet-stream
Size: 835169 bytes
Desc: not available
Url : http://lists.steptools.com/pipermail/wg11/attachments/20030529/455329c4/part11ed2.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part11ed2_with_change_marks.zip
Type: application/octet-stream
Size: 866696 bytes
Desc: not available
Url : http://lists.steptools.com/pipermail/wg11/attachments/20030529/455329c4/part11ed2_with_change_marks.obj
More information about the wg11
mailing list