William Kent
Database Technology Department
Hewlett-Packard Laboratories
Palo Alto, California
January 1993
CONTENTS:
> INTRODUCTION . . . 2
> GENERAL . . . 3
> 2.2 TYPES AND INSTANCES . . . 3
> 2.2.1 INHERITANCE . . . 3
> 2.2.2 EXTENTS . . . 4
> 2.2.3 IMPLEMENTATIONS, CLASSES . . . 4
> 2.3 OBJECTS . . . 4
> 2.3.3 OBJECT IDENTITY . . . 4
> 2.3.4 KEYS . . . 5
> 2.3.6 PROPERTIES OF OBJECTS . . . 5
> 2.3.7 OPERATIONS ON OBJECTS . . . 5
> 2.3.8 OBJECT LIFETIME . . . 7
> 2.3.9 LITERALS (IMMUTABLE OBJECTS) . . . 7
> 2.4 MODELING STATE - PROPERTIES . . . 8
> 2.4.1 ATTRIBUTES . . . 9
> 2.4.2 RELATIONSHIPS . . . 9
> 2.5 MODELING BEHAVIOR - OPERATIONS . . . 9
> EXCEPTIONS . . . 9
> 2.6 STRUCTURED OBJECTS . . . 10
> STRUCTURES (P2-17) . . . 10
> STRUCTURED LITERALS (IMMUTABLE COLLECTIONS) (P2-18)
. . . 10
> 2.6.1 COLLECTIONS (MUTABLE) . . . 11
> LISTS . . . 12
> 2.6.2 ITERATION OVER COLLECTIONS . . . 12
> 2.6.3 BUILT-IN COLLECTION SUBTYPES . . . 13
> SETS . . . 14
> BAGS . . . 14
> LISTS . . . 14
> ARRAYS . . . 15
> 2.7 FULL BUILT-IN TYPE HIERARCHY . . . 15
> 2.7.1 ACCESS TO THE METADATA . . . 15
> TRANSACTIONS . . . 15
> 2.9 OPERATIONS ON TYPE DATABASE . . . 15
> 2.10 FUTURES . . . 16
> MISCELLANY . . . 16
These comments are based on Chapter 2 only, specifically the version available in 1/93. Responses are solicited for each numbered item below.
To do:
In references to the text, P=page, L=line, L-n means n lines from the end, B=bullet, S=section.
The following graph is included here just for convenient reference...
Denotable_Object
--Object
----Atomic_Object
----Structured_Object
------Structure
------Collection (Mutable)
--------Predicate_defined
--------Insertion_defined
--Literal
----Atomic_Literal
----Structured_Literal = Immutable_Collection = Extensional_Collection
------[Literal-Filled_Immutable_Collection] (See item 107.)
Characteristic
--Operation
--Property
----Attribute
----Relationship
Most concerns such as raised below should be answerable without reference to language bindings. Language bindings should only deal with syntactic variants of model semantics. It would also be appropriate to answer many of these questions in Chapter 2, rather than deferring them to the ODL presentation in Chapter 3 (especially since P2-1L21 says that Chapter 3 provides syntax).
1. It should be made clearer what is and is not in the base model.
2. There seem to be three sorts of types: object types, literal types, and characteristic types (Fig 2-2). Does the unqualified term "type" always refer to all three? E.g., do they all have interfaces, implementations, subtypes, instances, and extents?
3. P2-2. If types are themselves objects, is Type a subtype of Atomic_Object? Can types be created like ordinary objects? Do they have oid's? Immutable collection types might not (see item 104.).
4. P2-4S2.2.1L8. As stated, the essential nature of an abstract type is that its instances must be instances of its subtypes. Why can't an abstract type have corresponding implementations which are inherited by all of its instances (subclasses)? S2.2.3 says a type has one or more implementations. S2.3.5L-1 admits the possibility of such implementation inheritance.
5. P2-5L2. Why does operation redefinition take the form "Become_larger() redefines B.Expand" rather than defining the Expand operation on type D? Are Become_larger and Expand both invocable operations on instances of D?
6. Why isn't redefinition described in Chapter 2?
7. P2-5L5: "...the application builder may only define subtypes within the tree below type Object." P2-11L7: "The type programmer may define subtypes of type Literal." (See item 69.)
8. P2-2B2 & S2.2.2. Is an extent a Collection object, as implied by P2-19L12? Is there a relationship between a type and its extent? Should this be included in the properties described for type Type on P2-27S2.7.1?
9. P2-2B2 & S2.2.2. Why is Extent described in terms of maintaining an index? Isn't that implementation? It would seem that the only appropriate semantic concern is whether or not the extent of a type can be retrieved. Even the question of whether the extent is stored or computed, e.g., as a query, should be left to implementation.
10. Does the type definer specify whether a type has an extent? P2-4S2.2L5 seems to suggest that every type has an extent. P2-10S2.3.9 implies that every literal type has an extent.
11. P2-2 & S2.2.3. What would an example of multiple implementations for a type look like?
12. S2.2.3L10. What is meant by "the scope defined by a type"?
13. S2.2.3L11. What is meant by "lexically separate"?
14. P2-6L9. Does the programmer have to explicitly choose the implementation (class) when creating an object? Can an application be written such that the source code is neutral to the choice of implementation?
15. Can an application be used with all implementations of a type, e.g., for objects not created by the application?
16. The unqualified term "object" seems to have three meanings: (a) the type Object and its subtypes, (b) the type Denotable_Object and its subtypes; and (c) the union of (b) with Characteristic and its subtypes. It is important to clarify what each occurrence of "object" means in the document. For example, S2.3.1L1 is one place where the term has meaning (b).
17. The notions of mutable and immutable should be defined. What is clear is that the model does not permit attributes or relationships to be defined on literals. Hence by definition there is nothing to mutate. (The model currently does not allow the definition of a function which, for example, maps numeric grades into letter grades. If this were permitted, then this could be considered a mutable property of a literal if the mapping could be changed.) Another possible distinction is that mutable objects need to be explicitly created or registered (e.g., to have an oid assigned), while immutables have a "natural" existence, either eternal (like numbers) or dependent on some criterion (e.g., any extensional set exists if its instances exist).
The term "oid" is appropriately defined as a representation of the identity of an object (P2-7L2), and nothing more. I don't see how to interpret this as anything other than the identity of an existing object. I don't understand the notion of the oid of a non-existing object. Hence...
18. "Oid" and "name" seem to be inappropriate as argument types in operation signatures. Signatures designate the type of operand denoted by the argument (e.g., a Section or a Course or an Integer or an Object), not the form of representation.
19. Since Name is defined on type Object (S2.3.6), why is it explicitly declared in Fig 2-1?
20. How is an object given a name? Can it be changed?
21. How does a name differ from other attributes, other than the broad uniqueness constraint?
22. Is uniqueness of names affected by case sensitivity? Can that be different in different language bindings? Does it follow that naming conflicts might arise if an object is referenced from code written in different languages?
23. A name differs from an oid in that (1) names are user-assigned, and (2) not all objects have names. Is there any other difference?
24. S2.3.4. Does the notion of "key" apply to all properties or only to attributes?
25. S2.3.4. The semantics of a key are that no two instances of the type may have the same value of the property. Whether it is enforced by indices is a matter of implementation which should not be discussed here.
26. S2.3.4. Is the notion of key well defined for set-valued properties, or for other non-atomic literal values? For sets it could mean that no two instances may have the same set of property values, or that no two instances could share any property value.
(What a long list of concerns for such a short section!)
27. S2.3.6. Is "Has_name?" an operation or an attribute? If attribute, it is presumably non-settable.
28. S2.3.6. Is Name an operation or an attribute? Can it be set like an ordinary attribute?
29. S2.3.6. Since an object can have more than one name (S2.3.3L11), shouldn't the value type for Name be {String}? Will retrieving the Name property return the whole set of names?
30. S2.3.6. Since types are objects (P2-2L9), isn't the Type property a relationship? Is Type in fact a traversal operation?
31. S2.3.6. Can the Type property be updated?
32. S2.3.6. Presumably the value of the Type property is the immediate type of the object.
33. S2.3.6. Has it been established somewhere that an object has only one immediate type?
34. S2.3.6. Is there a naming problem if Type is the name of a type and also of a property (relationship or traversal operation)?
35. S2.3.6. Type_name is not a type, and it should not be the result type of the Type property. If the Type property returns a type, then the result type should be Type. Otherwise, if it returns a type name, the result type should be String since names are strings (the result type of the Name property).
36. S2.3.6. Do all these properties apply to structured objects, or only to atomic objects?
37. Please verify the following assumptions:
- An operation defined on a type is applicable to instances of that type. P2-1B3: "The behavior of objects is defined by a set of operations that can be executed on an object of the type, e.g., you can `format' an object of type Document."
- An object has to exist in order to have an operation applied to it. Thus an operation defined on type Object, such as Delete, can be applied to an existing object.
38. S2.3.7. If the previous assumption is correct, to what existing instance of Object is the Create operation applied? It seems that Create cannot be considered to be defined on type Object. It could be defined on types Procedure, Process, or Database to establish the lifetime of an object, if those things were types. It might also be defined on type Type as a means of establishing the type of the object: applying a Create operation to a type object would create an instance of the type. More precisely, Create might be defined on a subtype of Type called Instantiable_Type.
39. S2.3.7. How is the (initial) type of an object established?
40. S2.3.7. What is the signature of the Create operation? What sort of argument type is "property = property_value"?
41. S2.3.7. Couldn't the result type of the Create operation be denoted in the form
List
42. S2.3.7. The Exists? operation is also hard to understand if an operation can only be applied to an existing object. It would seem more appropriate to define an operation which takes some sort of token (bit string?) as argument and returns true if that token is currently a valid oid.
43. Please verify the following:
- An operation op may be defined on a "target" type T with optional arguments of types Ai and result type Ri. The signature of such an operation can be denoted with the notation T::op(Ai)->Ri.
- An operation defined on type Object and taking an argument of type Object might be denoted
Object::op(Object)->Ri.
- The types in a signature refer to the object types, not the form of representation. In particular, "Object_id" is not a valid type in a signature.
- In an invocation of an operation, names and oid's of objects may be used interchangeably.
44. S2.3.7. If the preceding assumptions are correct, then the signatures of the two "Exists?" operations and the two "Same_as?" operations seem to be invalid, for two reasons. First, they include the target as an argument. Second, they use Object_id as an argument type.
45. S2.3.7. Also, don't the two operations named "Exists?" (and the two operations named "Same_as?") defined on type Object violate the overloading rules (P2-15L1)?
46. S2.3.7 & P2-7L4. How does "Same_as?" relate to "Equal?"? Why do we need "Same_as?" if "Equal?" is inherited from Denotable_Object (P2-7L4)?
47. P2-9L3. Does the notion of optional arguments imply that an operation can be defined to take a variable number of arguments? Or is this meant to refer to a list of arguments?
48. P2-9L4. Whether and when storage is allocated for an object seems to be a matter of implementation. An object could be created with no initial values for any of its properties, requiring no initial storage. Storage could be allocated incrementally as property values are established. In any case, update of properties could create a need to incrementally allocate more storage.
49. P2-9L11. Similarly, deletion does not necessarily require that storage be reclaimed immediately. Garbage collection could occur later.
50. P2-9L14. Why should an attempt to traverse a relationship raise an exception? If a student is deleted, then traversing the Students relationship on a section simply does not include that student in the result.
51. P2-9L14. Shouldn't similar maintenance occur when the deleted object was the result of any operation?
52. S2.3.7 & S2.3.8.How is the lifetime of an object established?
53. S2.3.8. Are procedures, processes, and databases all objects?
54. S2.3.8. The semantics of these lifetimes appear to be described in language-specific implementation terms.
55. P2-10. Are the types Character and String defined? Is either of these the type which contains character strings? Are readers and users of this model presumed to be C programmers?
56. P2-10L-1. Is the object nil an instance of the type Object?
57. Is Null a subtype of all types, or a subtype of all subtypes of type Object? I.e., is it a subtype of all literal and characteristic types?
58. Making Null a subtype of all types (in either sense) raises the following problems:
- It will never be possible (in a future enhancement) to specify any types as being disjoint. They always have at least one instance in common.
- Every type has an instance as soon as it is created. In general, every type will contain one more instance than were inserted by users. Counting the instances of Employee will yield one more than the real number of employees. Any query over Employee will return one more result than the user might have expected.
- If it were possible to specify that a property or operation is total, i.e., non-null, then values would have to be assigned for the nil object. Thus nil might have to have a birthdate, name, employee number, department, drawing number, part number, student-id, etc. etc. etc.
- Alternatively, a whole lot of rules in the model would have to be qualified to exclude the nil object.
59. P2-11L1. If Enum is a type generator rather than a type, then it does not belong in the type graph or in the list of types.
60. P2-11L1. Is Enum the same sort of type generator as described in S2.6.1 (see item104.)? What are the types that it generates? Are they objects? Instances of type Object? Do these type objects have names? See item 3.
61. P2-11. Where do these types fit into the type graph? They are clearly not subtypes of type Object. They seem likely to be subtypes of type Literal. Are they direct subtypes of type Literal?
62. P2-11. Would Enum types be any different if they were described as subtypes of Character?
63. P2-11. Is it possible to declare an Enum type whose instances are recognized to be integers, inheriting the operations defined in integers?
64. P2-11. Can an Enum type be defined by range? Wouldn't that require the Enum type to be a subtype of some other type in order to infer the elided members?
65. P2-11L3. The notion of name is only defined for instances of type Object (S2.3.3 & S2.3.6), which also have oid's. Instances of Enum types do not have oid's.
66. P2-11L3. What are the equality rules for Enum types? Is it based on name matching, even across different Enum types?
67. P2-11L6. "The built-in types Literal and Atomic_Literal are not modifiable." What does it mean to modify a type?
68. P2-11L7. Can subtypes of subtypes of Literal be defined, e.g., subtypes of Integer?
69. P2-11L7. Although subtypes of type Literal can be defined, apparently these still can't have operations or properties defined on them. Thus at most such subtypes of literals can occur as argument or result types for operations defined on subtypes of Object. Thus, although one could define letter grades as a subtype of Char, one cannot define a function which maps these into numeric grades (or vice versa). Is that true?
70. Suppose there were three implementations of type Circle, one storing the radius and computing the diameter, one storing the diameter and computing the radius, and one storing both, keeping them in sync when either is updated. Is it possible to distinguish between the state and the behavior of this type of object? (A similar example arises with spatial points, for which one or more of the following might be maintained: rectangular coordinates, polar coordinates in degrees, polar coordinates in radians, and latitude/longitude.)
71. Suppose a type definer wanted to define three functions on spatial objects:
- One to return the current location of an object.
- One to move the object to a new location, i.e., changing its location.
- One to shift the object by a specified displacement from its current location, returning the new location.
On what basis should the type definer decide whether to specify these as operations, attributes, or relationships? If locations are literals, must the first two operations have names of the form get_x and set_x?
72. What's the difference between an attribute and a relationship which can only be traversed in one direction? Note that Fig 2-1 does not explicitly differentiate between attributes and relationships, lumping them both under the heading of "properties".
73. Is there such a thing as a non-updatable attribute? How does it differ from an operation?
74. What's the difference between an operation and a relationship for which only one traversal operation is defined?
75. Are the following statements about the model true? Are they consistent? Does "object" mean the same thing in each case?
- Operations apply to objects.
- Characteristics (operations, attributes, and relationships) are not objects.
- The Invoke operation applies to operations, Get and Set operations apply to attributes, and traversal operations apply to relationships.
76. P2-3B3. It may be worth observing that the cardinality of a relationship is never declared directly. It is implied by whether either of the traversal functions is atomic- or set-valued.
77. Can the cardinality of a relationship be determined if only one traversal function is defined?
78. P2-12L2. On what type are set_value and get_value defined? What are the instances to which these operations apply, and how are they identified? These questions should be answered if set_value and get_value are part of the base model. Why are there no examples of setting and getting attribute values?
79. P2-12L15. I thought attributes and relationships both defined abstract state.
80. P2-14L18. How can we have operations defined on relationships when there really aren't relationships, only traversal operations (sometimes paired)? As the footnote says, full signatures need to be defined.
81. P2-14L18. How can we have signatures for these operations if the relevant types aren't in the base model?
82. P2-14L18. How does the "traverse" operation relate to the execution of a traversal operation? How do create, delete, add_member, remove_member relate to the update of traversal operations? Can they be used to update any operation that returns results?
83. Are operations defined on Objects, Literals, and Characteristics?
84. Is it possible to define an operation to simply retrieve some stored data? Does the form of the stored data need to be defined in the type specification?
85. P2-15L6. Operations are dispatched on the basis of the target object, which is not an argument.
86. P2-15L11. Why is "set of objects" particularly mentioned here? Isn't a set of objects a denotable object? Can't operations return other collections besides sets?
87. P2-15L11. The description of an operation signature (P2-14S2.5L3) doesn't mention distinguished results. Isn't the whole result considered to be the value of the expression?
88. P2-15L21. The absence of formal specification of the semantics of an operation seems to be the principal reason for the presence of attributes, since it provides a semantic specification of the connection between set and get operations. If the model included such specification capability, then the semantics of attributes would be subsumed by the capability to specify that one operation alters the results returned by another.
89. P2-15L24. In what sense are these operations provided in the base model? What are their signatures?
90. Why doesn't the document describe the form (semantic elements, not syntax) of an invocation? The form target.op(args) is only suggested by examples.
91. P2-15L-7. What does "open coding" mean?
[I skipped this section.]
92. What are the retrieval and update operations on structures? This is only hinted at by the example "address.zip_code=01907", which makes a slot appear to be an attribute.
93. How are slots in a structure different from properties of an object? A slot seems to be like an attribute if it contains a literal, and like a one-way relationship traversal operation otherwise. Note that Structure is a subtype of type Object, hence each structure instance is an object with an oid. (Consequently, the Dictionary illustrated at P2-17L-3 seems indistinguishable from an object type with two properties defined on it.)
94. How is a structure instance created?
95. Presumably a structure cannot be the value of an attribute, since it is an Object.
96. Are slots objects?
97. Does "name" mean the same thing as the name of an object (P2.7)?
98. Can two distinct structure instance have the same named slots and values? Is Equal defined to mean object identity or matching slot names and values?
99. P2-18L10&L13. Some confusion about set identity can be reduced by speaking of two references to sets rather than two sets. If there are two sets, they are not the same set. Thus it is not appropriate to speak of two sets which have two names as being the same set; rather, we have two names for the same set. Similarly, "unicorns" and "living kings of France" are not two sets, but two descriptions of the same set. The designations "unicorns" and "living kings of France" might better be thought of as naming set collection objects, both of whose values happen to be the empty set.
100. P2-18Footnote 7. There is a simpler way to introduce structured literals (immutable collections) than to replicate so many structures and descriptions.
- Much of the material in Section 2.6.1 could be moved into a separate section describing structured literals (immutable collections). I will use "Imm" and "Mut" prefixes to distinguish the two sorts of collection types, e.g., ImmSet and MutSet for extensional and mutable sets, respectively.
- An instance of a mutable collection type (i.e., a structured object) could then be treated as a simple mutable object with a "Content" property whose value is a structured literal, constrained to be an instance of the corresponding immutable collection type. For example, an instance of MutSet(Employee) is an object whose Content is constrained to be an instance of ImmSet(Employee). Certain operations, such as set union, would be defined on the structured literals; corresponding operations on structured objects would naturally be interpreted as operations on their contents. Thus, if + denoted union of immutable sets, and Managers is an instance of MutSet(Employee), then inserting Dick into Managers could be abstractly described as
Managers.Content <- Managers.Content + {Dick}.
Some other assumptions about structured literals that could be confirmed or discussed:
101. (Assumption) Structured literals are not explicitly created or destroyed, and they do not need oid's. Expressions such as {1,2} and {Dick,Jane} designate existing immutable sets rather than creating anything new, just as 2+2 designates an existing number. Expressions such as {1,2}, {2,1} and {1,1,2} all designate the same set.
102. (Assumption) Structured literals have a natural kind of existence, like numbers. Thus all the immutable sets of numbers exist, and an immutable set containing Dick and Jane exists exactly whenever objects Dick and Jane exist.
103. (Assumption) A given structured literal may be both homogeneous and heterogeneous depending on how high up the supertype chain you go. {Dick,Jane} is heterogeneous since Dick is a man and Jane is a woman, and perhaps also if Dick is a programmer and Jane is an engineer. At the same time it is homogeneous since they are both persons, and perhaps also if they are both employees. Every structured literal is ultimately homogeneous, being a collection of type Denotable_Object. The set {Dick,Jane} is automatically an instance of Set(Employee) exactly so long as they are both employees.
104. (Assumption) Structured literal types, e.g., ImmSet(Employee), have a natural sort of existence; the type ImmSet(Employee) exists automatically when the type Employee exists. Any immutable set of employees is an instance of this type. There is no need to create or name this type; if it is given a name, then several such naming actions are providing aliases for the same type. A type generator like ImmSet() is simply a means of designating existing types. ImmSet(Employee) designates an existing type in the same way that {Dick} designates an existing immutable set. ImmSet(T) designates a structured literal type for any type T. (There is, obviously, infinite recursion here. There is an infinite number of set types.) If there were also to be a type named ImmSet, it would be equivalent to ImmSet(Denotable_Object). The type ImmSet(T) is a subtype of ImmSet(U) if and only if T is a subtype of U. The type graph contains an infinite number of subtypes of ImmSet(Denotable_Object). These types probably don't have oid's. [Analogous details may vary a bit for other kinds of structures.]
105. (Question) Structured literal types can occur as argument or result types in the signatures of operations and properties. Where else do they occur?
106. (Issue re P2-23L2) A query should return a structured literal (immutable collection), not a structured object with an oid. It's not at all apparent why each execution of a query needs to yield an object with a new oid, particularly if it is really the same query. Desired semantics can obtained when needed by assigning the result of a query to be the value of a collection-valued variable or the content of a structured object.
107. (Assumption) For the ODMG model, an important special case (subtype?) of structured literals might be called "literal-filled". The elements of a literal-filled structured literal are either atomic literals or, recursively, literal-filled structured literals. Values of attributes are either atomic literals or literal-filled structured literals. (See footnote 3 on P2-12, which refers to P2-11L-2.)
108. P2-3B4. Where/how do named instances of collection types occur? Which are the collection types? Does "named instance" refer to a particular such type, or to a member of such a type? What is the "instance" notion here?
109. P2-17L8 & S2.6.1L2. Any set of objects is of the same type if you go high enough in the type graph. Ultimately they are all instances of Denotable_Object. The remark here about "same type" can't mean same immediate type, since a programmer is allowed to belong to a set of employees. The strongest statement that can be made here is that a collection of a specified type may only contain elements of that type.
110. P2-17L12. What are the signatures and semantics of insertion operations? Insertion of elements should really be described as replacement of one structured literal with another, analogous with incrementing an integer.
111. P2-18S2.6.1L3. What is an instantiable type?
112. P2-18S2.6.1L3. Why may collections only be defined over instantiable types?
113. P2-18L-2. A type generator for structured literal types is essentially a means of designating an existing literal type, as described in item 104. A type generator for mutable collection types might be used to define a type whose instances all have the same ContentType property. It remains to be clarified whether this facility is needed and what its detailed description would be.
114. I don't understand what is being illustrated at the top of P2-19.
115. Perhaps walking through an example might help to clarify things...
Let people's names denote existing objects, instances of Person.
{Dick,Jane} denotes an existing immutable set, which is a structured literal, immutable collection, extensional collection.
ImmSet(Person) denotes an existing type, which has no oid. {Dick,Jane} is an instance of this type.
Let "Person::Children: ImmSet(Person)" be the signature of an operation or property on type Person. It is legal to make {Dick,Jane} be a result of this operation or value of this property on some person.
[I assume that {Student} in Fig. 2-1 means ImmSet(Student).]
Let's assume that I can create a (mutable) structured object named Bowlers, with ContentType=ImmSet(Person). [Exactly how would I do that?]
It would be legal to make {Dick,Jane} be the Content of Bowlers. [How would I do that?]
In what operation could I use Bowlers?
Why do we need structured object types?
Why do we need type generators for structured object types?
116. P2-19L10. How would the ordering of a predicate-defined collection be established?
117. P2-19L13 thru L19. "Creating an object ... should go in the collection" is confusing. It would be much clearer to simply say that the base model does not recognize user-defined predicates. The intent of the collection is in the mind of the user, whose responsibility it is to correctly maintain the collection.
118. P2-24L-1. I thought insertion points (hence order) can be arbitrary via a cursor.
119. P2-17L12 & S2.6.2L2. What does "position" mean for unordered collections? I don't understand the last paragraph of S2.6.2.
120. P2-20. A cursor has a position, and a cursor operation returns a result. What does the "value of a cursor" mean?
121. P2-20. Can the nil object occur in a collection? Multiple times in a bag? If yes, then a nil "value" of a cursor could be misleading.
122. P2-20. Why do cursor operations return 0 instead of nil? Wouldn't that create problems when iterating over collections which don't contain integers?
123. P2-19bottom & P2-20L12. Why do we need a type generator for cursors? Why do we need subtypes of type Cursor, as this implies? Cursor could be a simple built-in type. A Create_Cursor operation could be defined on the type Collection; when applied to a collection object it creates a cursor for the type of that collection.
Note: I am using terms like MutSet and ImmSet to differentiate between the two sorts of collection types.
124. Again, a type generator is not a type. There may be a type such as MutSets which is the supertype (union) of all types generated by a generator MutSet(), but the type is not the generator. A generator is more like an operation whose evaluation returns a type. The type MutSets equivalent to MutSet(Denotable_Object); this is true for all the collection types defined in ODMG.
125. Also, again, the term "generator" could itself be misleading. A generator expression usually designates an existing thing, rather than creating a new thing. The difference is significant: two executions of the same generator expression designate the same thing, rather than creating two distinct things.
126. P2-21L13. As before, a create operation shouldn't be defined on the type Collection, since it cannot be applied to an existing instance.
127. P2-21L13. What sort of argument type is pragma? Is it an Enum? (And again, why this sort of syntax in the signature rather than {pragma}?)
128. P2-21L16. What does Collection
129. P2-21L16. The argument type named "pragma" here seems to designate a different Enum type from L13.
130. Is there some reason why built-in operations should not be describable by the same signature semantics as user-defined operations?
131. P2-21L18. What does this traverse operation mean? Does it have anything to do with relationship traversal operators?
132. P2-21L21 & P2-22L-7. Why are the cursor-based functions defined on Collection? Aren't they applied to a cursor, which is itself associated with a collection? Why are these treated differently from the retrieval operations on cursors?
133. P2-22L-7. Does "function" mean "operation"?
134. P2-21L26. Does "Exists?" mean non-empty, i.e., Cardinality>0?
135. P2-21L27. Occurs might be more useful than "Contains?", yielding the number of occurrences. This is not currently provided for bags.
136. P2-21L-1. Does the notion of "reference to a set" have anything to do with model semantics? How does it relate to the notions of a structured literal and the oid of a structured object?
137. P2-23L11. The definition of a type family such as Set
138. P2-23L14. Why do the create and insert operations need to be refined?
139. P2-23L17. Does each execution of union, intersection, or difference really create a new structured object, with a new oid? That wouldn't be necessary if such operations were only defined on immutable sets (see item 100.).
140. P2-23L20. Why is copy defined here? It was defined for Collection.
141. P2-23L21. In these four predicates, which is a subset of which?
142. P2-23. Is it understood that Set
143. P2-23L25. The phrase "or a subtype of T" is redundant.
144. P2-24L7. What is this notion of "shallow copy"? The underlying concern seems closely related to item 136.
In addition to many of the same concerns as were raised about sets...
145. Is it understood that Set
146. If such subtyping were recognized, then it might not be necessary to define much for sets. Operations on bags could be defined in such a way that they work correctly when inherited by sets. Union could be defined such that the result contains the maximum number of occurrences of an element in either set, while Concatenate could be defined so that the result contains the sum of the number of occurrences. If both operands happen to be sets, then Union would yield a set while Concatenate might not.
147. If such subtyping is not recognized, then why are some operations which are defined for bags not similarly defined for sets, e.g., remove, query, replace? Conversely, why aren't there bag counterparts for is_subset etc.?
148. P2-25L4. Why is the inheritance of query mentioned here but not for the other collection types?
149. P2-25L6. How are these operations related to operations which can be performed via cursors?
150. P2-25L17. What is "current position" within a list?
151. P2-25. What is the cardinality of a list? Is it the highest non-nil position, or the number of non-nil positions?
In general, there could be considerably more consistency in the definitions of operations on collection types, and in the manner of their inheritance from the type Collection.
152. P2-25. How is the length of an array established? It would seem that the type
generator for arrays should have an additional parameter: Array
153. P2-25. Is it an error to access beyond the end of an array?
154. P2-25. Is the cardinality of an array the fixed length, or the number of non-nil positions?
155. P2-25. Other than the fixed length, what's the difference between a list and array? Syntax aside, isn't x[12] the same as x.retrieve(12)?
VARRAYS
156. What's the difference between a varray and a list? Why is an initial size
semantically significant? Does it affect the cardinality? A better approach might be to
allow an optional pragma parameter on List
157. Where are the types Type, Null, Exception, Database, Cursor? Aren't they all built in? Are Procedure and Process types? And where are the generated types? Does the footnote at the bottom of P2-27 include all of these?
158. Why are Characteristic and its subtypes included? I thought they weren't part of the model. More generally, it would be useful to clarify what is and isn't in the base model.
Figure 2-2 on P2-27 is at least Figure 2-3. Also, the sub-graph under Characteristic appears to be improperly indented.
159. Does everything in this section really apply to type Characteristic and its subtypes?
160. Are the properties defined on type Type really in the base model, even if the types Operation and Property don't seem to be?
I have skipped this section.
Substantial scoping questions arise here. Until now it appears that the scope of a type is a single database. For example, I believe that different databases can contain types with the same name, and the instances of a type are all in the same database. In effect, each database has its own type graph (schema). Also, the scope of name and oid uniqueness is a single database (P2-7L14 & L25). Also, it seems implicitly true that one has to open a database before executing any operations on the instances of a type. If all that is true, then...
161. To what database does the type Database belong?
162. Where does the type Database fit into the type graph of a database?
163. What are the instances of this type? Are they instances of type Object? What is the scope of uniqueness of their oid's?
164. How can any operation, e.g., open, be executed before any database is open?
165. P2-30L3. Isn't any named object automatically a root? If not, what's a root?
166. S2.10.3 item 3. Does "representation" of an object mean its implementation? Or what?
167. In Fig 2-1, what sort of thing is Weekdays? Could it be an object type? Literal? Enum?
168. Would there be a way to define an operation that returned the sections offered on a particular day of the week?
169. In Fig 2-1, is grade_curve an attribute or a relationship? What are "no_of_students" and "grade"? Do attributes have result names in their signatures? Or are these names within a structure? If so, then grade_curve must be a relationship, since structures are not literals. How are we supposed to figure all this out? And if it doesn't really matter, then why differentiate between attributes and relationships, and why introduce structures in addition to objects with attributes?
170. P2-8L3. Why does the term "interface" occur here?
171. What would an instance of type Relationship be? They really don't exist in the model other than as traversal operations, sometimes linked as inverses, which are hard to distinguish from ordinary operations. If the instances of type Relationship are low-level instances, e.g., a specific student/section pair, where does the "Takes" relationship show up? Is the type definer defining a new subtype of Relation each time he defines a relationship? And how does that subtype thing relate to the pair of things which are the traversal operations?
172. And similar sorts of questions about instances of Attribute. [See bottom of P2-11.]
173. To put it another way, attributes and relationships have a funny kind of ambivalence. Although attributes and relationships are distinguished as subtypes of Characteristic, there are some ways in which they don't exist. For instance, the base model seems to have only traversal relationships, sometimes paired and sometimes not, rather than relationships. For another thing, the examples of type definitions, and the properties defined on type Type (P2-27), speak only of properties, without distinguishing between attributes and relationships.
174. Is it possible to "register" an existing thing (in order to give it an oid) which already has established property values, as opposed to creating it and initializing its properties?
175. Could raise some issues about jointly owned operations, multi-argument dispatching, etc. Why not allow overloading within a type with different signatures. Future?
176. Big question at the very end: if these objects exist and are identified only within one database, how do they relate to objects identified and managed by the ORB? How do these objects send and receive messages via the ORB?