William Kent
Database Technology Department
Hewlett-Packard Laboratories
Palo Alto, California
Feb 1993
> INTRODUCTION . . . 1
> GENERAL . . . 2
> 3 DEFINITIONS AND ABBREVIATIONS . . . 2
> 4 FRAMEWORK OF ABSTRACTIONS . . . 2
> 6 BASIC INTERPRETATION CONCEPTS . . . 2
> 7 BASIC LINGUISTIC CONCEPTS . . . 2
> 8 BASIC MODELLING CONCEPTS . . . 3
> 9 SPECIFICATION CONCEPTS . . . 5
These comments are based on SC21/WG7 N7054 CD10746-2.1 [Recommendation X.902: | Basic Reference Model of Open Distributed Processing - Part 2:] Descriptive Model (undated). In references to the text, P=page, S=section, B=bullet, L=line, L-n means n lines from the end.
Responses are solicited for each numbered item below.
To do:
Though the authors may wish otherwise, we may not yet be willing to assume they are infallible. In material as minimally written as this, it is necessary to verify that plausible interpretations are in fact intended. While it may seem logically redundant, this is in fact a very necessary reason to include paraphrase and examples. Examples are particularly useful as an "existence test" of internal consistency; ambiguities are often exposed when trying to reify concepts into examples. Similarly, it would be useful to emphasize things which the user is likely to miss due to subtle nuances of wording, or because they are only implied by indirect inference from what has been written.
Furthermore, since the document is intended to be very rigorous, I presume that it is fair to interpret each definition very precisely, i.e., to "split hairs" if needed to induce a clarification.
Though it may not be politic to say this, I believe there is a significant risk that many of the people involved in the approval process may not have fully read or understood the document and all its significant implications.
1. S3.2.1. Unless the term "discrete component" is otherwise defined somewhere, it would seem that subroutines qualify as discrete components, and distributed processing then includes subroutine calls. Is that intended?
2. It would seem that a complete description of any facility includes all five viewpoints. Shouldn't there also be some description of correspondences among constructs in the various viewpoints? For example, shouldn't things in the engineering viewpoint be verifiable implementations of things in the information viewpoint?
3. S6.1 & S6.2. Is a proposition an entity? It is an abstract thing of interest. Note that S7.1 hints at a broad interpretation of "entity". (Similarly, most other abstract things of interest herein would seem to be entities, e.g., actions and objects and predicates and types and interfaces etc. And it follows then that we can have objects that model all of these.)
4. S7.2. What is an example of a term which is not a name? The act of naming as defined here includes the application of some convention, and the meaning of any term is understood only by convention. What is the effective distinction between a term and a name?
5. S7.3. Is the implication here that a term or name may refer to one or more entities? It would help to mention that in S7.1 and S7.2.
6. S7.4. The term "predicate" deserves equally formal definition, particularly since the definition of "type" depends on this (S9.18, item 58.). The following paragraph suggests how a predicate "may be considered", but it's not a clear definition, and it uses more undefined terms (relationship, link). I would surmise that a predicate is a term which refers to a proposition (S6.2). If that's the case, then describing a sentence as containing terms and predicates is redundant. Also, does a predicate uniquely identify a proposition, or can it be ambiguous like any other term?
7. S7.4. The notion of "predicate" (and the related notions of proposition and type) presumably admits things which are simply true by assertion, rather than requiring that some criterion be satisfied. Thus you are a grinch simply because I say you are. Is there any basis for knowing what predicates (propositions, types) there are? How do they come into existence?
8. S8. It would be useful to have the concept of a request as distinct from the resulting action. A particularly important phenomenon is that objects participating in an action may not have been explicitly referenced in the request. For example, a request to register a student in a course may cause an action in which a registrar object or database object participates, though not mentioned in the request. There do not seem to be any basic modelling concepts with which to express this.
9. S8.1. Is there any notion of the result or consequence of an action? Is there a notion of an action raising an exception, or of having a result which then participates in another action (analogous to expression composition)? Those would seem to be basic modelling concepts. How are they accounted for?
10. S8.1 Note 1. Should we similarly assume that other unqualified terms also refer to occurrences or instances, e.g, entity, object, action, interaction, etc.?
11. S8.1 Note 3. Because of the terseness of this document, it would help to have a forward reference when a term is used before it is defined, as with "interaction" here. (And "template" at S9.5L-3.)
12. S8.3L3. In what sense is an object characterized by its state? To whom? Isn't an object entirely characterized to its external observers by its behavior alone, from which the observer might surmise things about its state? What does "characterized" mean?
13. S8.3L8. This clearly implies that an object can exist in a distributed fashion within a system, without being located in any one particular place. Is that intended? (I'm using "system", "located", and "place" casually, without further definition.)
14. S8.3L11. Would it be equally accurate to say that functions may also be performed on objects? E.g., a printer prints a document, a manager fires an employee.
15. S8.3L11. By the way, what is a function? On further reading, I find Notes 1 and 2 not very enlightening. "Action" and "behavior" are defined later. It would help to have formal definitions of "function" and "service", particularly to clarify how all four of these terms interrelate.
16. S8.3L11. Is every function performed by an object? If an object is a model of an entity (S8.3L1) rather than the entity itself, how do we describe the case where a person moves an icon? Is that a function? Which object is performing it?
17. S8.3 Note 3. This sort of remark, and probably others elsewhere, suggest an underlying assumption that all objects are active (dynamic) things, almost sentient. Is there no notion of passive objects, which merely have things done to them, though still governed by constraints? I can't see much value in the metaphor of, e.g., a document or a circuit board deciding what interactions it takes part in and when. Is there an underlying assumption that an object is something like an application, for example?
18. S8.4 & S8.5. Does "space" here mean a geometric space? The term also has other uses, e.g., as in a name space, an address space, or a problem space. If geometric, does it mean three-dimensional? Geographic? Relative to a coordinate system? Does the concept of "location in space" encompass location at a node in a network?
19. S8.8. This presumably refers to the behavior of an object instance, even though the specification might be associated with an object type.
20. S8.8. There seems to be a missing intermediate concept. Each time I load a document into a buffer, that's an "action" (S8.1), and so is each time that I print from that buffer. If I load and print twice, there are four actions. Each sequence of loading and printing constitutes an "activity" (S8.7); I just described two activities. "Behavior" is then defined here as a specification of a set of activities, which might include "all" the load/print sequences that ever have or ever will occur, as well as all the open/edit/close and open/edit/close/load/print etc. sequences. What is lacking is a term which corresponds to just "load", or to just "print", etc. Behavior specifications really contain terms which refer to these sorts of things, yet there is no corresponding concept defined here. Such a concept might be called "operation" or "function"; it might correspond to an activity type, in contrast to an activity instance. (E.g., at S8.8L4, in what terms are the constraints specified?)
21. S8.8L5. What does it mean to derive an activity?
22. S8.9. Can objects participate passively in an interaction? If an employee gets assigned to a department, is that an interaction between those two?
23. S8.10 - S8.12. These are circular and not very useful definitions. An observation run is a set of interactions, and an observable action occurs in an observation run. So? If there is no distinction between observing and participating, then "observation" has no useful meaning.
24. S8.12. What does it mean to say that an action "can" occur as part of an observation run? It either does or does not. (Remember that an action is an occurrence.)
25. S8.12. Based on S8.10, this seems to define an observable action with respect to a given tester object, implying there are different observable actions with respect to different testers.
26. If the performers and observers of actions are always objects, and objects are models of entities, how do entities get into the loop? How do people get any use from systems? How do I initiate an action, or observe a result? It would really help to introduce some notion of an "object system", with some notion of "system interface actions" which can be initiated and observed by entities outside the system. (Alternatively, if "everything is in the system", then entities are in the system, and we don't need a distinct notion of objects as things which model entities.)
27. S8.13. What space (see item 18.)? What do stability and mobility mean?
28. S8.13. Does every interaction necessarily take place at a point? Where does an employee get assigned to a department?
29. S8.15. Can there be a notion of state which is shared among objects, analogous to the ability of a function to be performed cooperatively by several objects (S8.3L17)? Can the fact of an employee belonging to a department be considered as shared state?
30. S8.15. I don't understand how state determines actions in which the object can take part. I can see that state may affect the outcome of the action. E.g., I don't see how the content of a document affects whether it can be printed; it does affect the output of printing.
31. S8.15L6. How is knowledge of state attainable, other then by inference from observed behaviors?
32. S8.16. Which observable actions? With respect to which tester? See item 25.
33. S8.16L3 and Note 1. I would expect an interface to be a specification described in terms of "operations", not action instances. See item 20.
34. S8.16. There are distinct notions of interface for object instances and object types. It would be useful to acknowledge this. (Though this may be related to later notion of template; see item 50.)
35. S8.16L4. At this basic level of modelling, why is it necessary to partition observable actions among the interfaces? Why can't they overlap?
36. S8.16 Note 2. I didn't understand the term "abstraction" at S8.16L1, and now I understand it less. What point is this note making? What misconception is it clarifying?
37. S9.1. Is this dealing with object and action instances? How would two action instances combine to create a new action instance?
38. S9.1a. Does "composition" refer to a process which yields a new object, or to the static fact that an object is composed of others? The mechanism for generating an object can be different from, and possibly unrelated to, the composition relationships it might have with others.
39. S9.1 Note. "Choice" does not seem to fit the description of composition as creating a new object. Doesn't this select an existing one? How would hiding or concealment fit the definition? The examples seem to suggest that composition refers to any sort of specification of an object which mentions other objects, without any other semantics of containment or part/whole.
40. S9.2. What does it mean to "express" an object?
41. S9.4. What is a model? What does it mean for an object (instance?) to be or not be part of a model?
42. S9.6L4. If "specifications and their refinements typically do not coexist in the same system description", then this is not the usual notion of refinement, which consider a subtype (or subclass) to be a refinement of a supertype (or superclass).
43. S9.6L12. This is a further extension of the definition, which did not initially constrain the transformation to preserve behavioural compatibility.
44. S9.7. Why is "trace" a specification concept?
45. S9.7. Which observable behavior? See item 25.
46. S9.7. Does an object have one trace, from its initial state to its current state, or a set of traces between pairs of states?
47. S9.7L4. "The behaviour uniquely determines the set of all possible traces, but not vice versa." What does that mean? This might depend on the question in item 20.
48. S9.8. Does a template really specify "the" common features, or only some common features?
49. S9.8L6. For a precise definition, it would be appropriate to differentiate between a "template generator", which is parameterized, and the template corresponding to a particular parameter.
50. S9.9. Are these the common features of a set of action instances? Should we understand an action template to be something like an operator specification (item 20.)? Or is it a set of operator specifications, being the type-level analog of an interface (item 34.)? Also, which observable actions (item 25.)?
51. S9.9 - S9.11. Given the preceding uncertainties about templates and interfaces, it's quite difficult to sort out what these things mean and how they differ from prior concepts. I would imagine that a very small fraction of the audience is able to keep things sorted out up to this point and beyond.
52. S9.12. Is it possible for an existing object to become an instantiation of a template, i.e., without the result being a new object? It would not seem appropriate to exclude this possibility at this basic modelling level. (See item 55.)
53. S9.13. What's the difference between object creation and instantiation?
54. S9.13 & S9.14. Why are the phrases "when ... performed by an object" necessary?
55. S9.15. "Introduction" might be an answer to the question in item 52. Is an introduced item an instance of a template? How?
56. Can an object be an instance of no templates? Of more than one template?
57. S9.16. Is an interface created as an instance of a interface template (S9.10)?
58. S9.18. Is there any concept which distinguishes a type from an arbitrary predicate? If not, what purpose does this definition serve? Also note that this term, which is considered quite central in most treatment of object models, rests on the undefined term "predicate" (item 6.).
59. S9.20L5 & S9.21L3. Sorry, I did not see any connection established between classes and templates.
60. S9.20 Note and Figure 1. I cannot find the chain of relevant definitions. It would help if they were called out by number. Also, the subtle apparent distinction between instance and instantiation is counter-mnemonic, and only contributes further to the difficulty of comprehending this document. The second paragraph under S9.21 is absolutely no help.
61. S9.21L3. Subclass was defined among classes (S9.20). How did it come to be a relationship between templates?
62. S9.21. Is a template a subclass of itself? Is an instantiation of a template an instance of that template?
63. S9.22L7. What is the representation of a template type? What has it got to do with anything as a basic modelling concept?
64. S9.22L8. What is the significance of template types being logically equivalent? Does it mean they have the same instances (or instantiations)? Does it follow that an object can be an instance (instantiation?) of more than one template type?
65. S9.23. Do logically equivalent template types share the same template class?
I stopped reviewing section 9 at this point. There's too much uncertainty in the previous concepts to be able to deal with anything more built on top of them.
The remaining items below represent random spot checks, and do not imply that intervening portions of the document have been reviewed.
66. S10.1 Notes. Are we expected to know what it means for objects to be addressed, or to have fault dependencies?
67. S10.2. What is a bound interface? (S13.4.2 comes too late, and is beyond the point where I stopped trying to follow the sequence of definitions.)
68. S10.4. What does it mean for an object to exhibit behaviour (over a period of time)? I thought a behavior was a specification of a set of activities (S8.8).
69. S12. Does the notion of name encompass object identifiers?
70. S12.2. This section seems to introduce identification of objects, but not of interfaces.
71. S12.2. Can an object have more than one distinguished name? More than one per domain?
72. S13.1.9. Does this notion of operation relate to item 20.?
73. It is difficult to understand the distribution of topics over the various sections of this document.