Comments received on ISO/IEC 13719 : PCTE version 3 - 12 September 1995 S.J.Dawes - UK Introduction ------------ This document contains all the comments received to date on the PCTE Standard ISO/IEC-13719, parts 1, 2, and 3. These comments come from the following sources: EP-4041 to EP-4310. Comments on DIS 13719 which were resolved by the PCTE fast-track Ballot Resolution Meeting (Geneva, 5 - 8 July 1994) but which for one reason or another could not be incorporated in ISO/IEC-13719 EP-4346 to EP-4423. Comments on DIS 13719 which were raised too late to be included in Ballot Resolution Meeting. EP-5001 on. New comments received after the Ballot Resolution Meeting. I have retained the ECMA/TC33 comment numbering system (starting new comments from EP-5001) and the format of comments with one addition: !recommend contains the recommendation by ECMA/TC33 for resolution of unresolved comments EP-4346 to EP-4423, taken from the document 'Draft Answers from ECMA TC33 to additional comments generated during the resolution of the National JTC1's Comments on the Fast Track of the DIS 13719-1/2/3', distributed as PCTE-GENEVA-5 at the Ballot Resolution Meeting. An index of comments is given in Appendix B. Note that in EP-4041 to EP-4423, clause or paragraph numbers refer to edition 2 of the ECMA standards, while in EP-5001 on they refer to ISO/IEC 13719 edition 3 (for the paragraph numbering see edition 3 of the ECMA standards). A cross- reference listing is given in Appendix A. This third edition includes new comments received since publication of the second edition on 4 May 1995. ----------------------------------------------------------------------------- !identifier EP-4041 !status unresolved !sender Martin Kirby/mwk@sdsph.sdsci.co.uk/EDS !reference EP_EDS_ECMA_149/69 !date 1994-01-10 !clause Part 1/15.1.1(8) and others !priority medium !title Transaction rollback of moved objects !comment When an object is moved its volume identifier is changed and MOVE_EVENTs can be sent. If the move occurs in a transaction then it is subject to rollback when the acquired WTR lock is discarded. Presumably a notification message is sent at that time. This is not very clear. Or is the statement that the move is subject to rollback incorrect. The volume identifier is supposed to be that of the volume from which the object_on_volume link emanates but that link has been changed without benefit of locks so presumably is not rolled back on lock discarding. 16.1.2(11) does not exclude volume identifier from the object resource. The area seems confusing - what is meant to happen? !discussion DI-4041/1 !sender JC Grosselin/Emeraude !date 1994-05-18 As ECMA is actually specified, no notification message is sent when a lock is discarded. However I think that a message should be sent when a lock is discarded to the message queues which have previously received a message when a modification occurs. !history Agreed at TGOO-05. Resolution not included in ISO/IEC 13719-1 as too vague. At WG22/1 B.Bird agreed to study further and propose solutions. !resolution TGOO-05: Add to Part 1/15.1.4 that on transaction rollback, notification messages are sent notifying rollback and no messages are sent to non-enclosed activities. Also, a statement to be added to clause 16 to the effect that object_on_volume links are subject to rollback with their destination object although not locked. ------------------------------------------------------------------------ !identifier EP-4068 !status unresolved !sender Martin Kirby/mwk@sdsph.sdsci.co.uk/EDS !reference EP_EDS_ECMA_149/109 !date 1994-01-10 !clause Part 1/10.2.16, 10.2.17, 10.2.18, 10.2.19 !priority medium !title Omitted access errors from SDS_IMPORT? !comment The SDS_IMPORT... operations define the annotation of the new types as being copied from the corresponding type in the from Sds. However, no ACCESS_ERRORS are listed for these type-in-sds objects. Since the annotation is a user modifiable attribute it can be modified when the type-in-sds object is accessible but the sds is not. If an import occurs at that time then the updated annotation cannot be fetched. Proposed resolution: There are two ways this could be addressed: a) Add the ACCESS_ERRORS states, which implies that we hold the annotation on (or about) the representational OMS Object and all imports have to reference the OMS object b) Hold the annotation on the type-in-sds instance in the sds in which case the set attribute operation for the annotation attribute of a type-in-sds object could fail because the type- in-sds object was accessible but not its containing Sds. (a) is an approach closer to the standard. (b) is an approach closer to the underlying requirement. Since type-in-sds objects shouldn't really be divorced from their sds I tend to favour (b). !discussion DI-4068/1 !sender JC Grosselin/Emeraude !date 1994-05-18 AGREED (a) seems to be more apropriate. !history Agreed at TGOO-05. Resolution not included in ISO/IEC 13719-1 as too vague. The choice of (a) was preferred at WG22/1; B.Bird agreed to discuss with M.Kirby and see whether there is really a problem with solution (a). !resolution TGOO-05: Proposed resolution (a) agreed. ------------------------------------------------------------------------ !identifier EP-4069 !status unresolved !sender Martin Kirby/mwk@sdsph.sdsci.co.uk/EDS !reference EP_EDS_ECMA_149/110 !date 1994-01-10 !clause Part 1/23.2.5, 23.2.6 !priority medium !title Confusing error returns setting object references !comment 23.2.5 and 23.2.6 OBJECT_REFERENCE_SET_... list relatively few errors including the error PATHNAME_DOES_NOT_DESIGNATE_AN_EXISTING_OBJECT However, clause 23.1.2.1(10) indicates that evaluation occurs with point NOW and 23.1.2.2(19) et seq. nearly list some errors that come from evaluation - nearly because the list is only applicable to external object reference evaluation. My assumptions are: a) 23.1.2.1(19) should apply to all evaluations of object references b) PATHNAME_DOES_NOT_DESIGNATE_AN_EXISTING_OBJECT should be returned only if evaluation point is NOW and if for the last link in the pathname the link's destination does not exist - for intermediate non existing objects LINK_DESTINATION_DOES_NOT_EXIST should be returned. !discussion DI-4069/1 !sender JC Grosselin/Emeraude !date 1994-05-18 PARTIALLY AGREED a) not all errors should apply to the evaluation of an internal reference (21), (24), (25) b) I suggest to remove this error because with the proposed meaning it should also apply with the other evaluation status when the reference is used. !history Agreed at TGOO-05. Resolution included in ISO/IEC 13719-1 except part [2], not included as too vague. At WG22/1, J.Dawes agreed to propose wording for [2]. !resolution [1] On p.273, move (22) to below (26). [2] 23.1.2.1(10) extended to include input parameters to operations in clause 23. [3] 23.2.5(3): delete [4] 23.2.1(4): delete [5] 23.2.5(4), 23.2.6(6): delete, and also the error in C.4 ------------------------------------------------------------------------ !identifier EP-4071 !status unresolved !sender Martin Kirby/mwk@sdsph.sdsci.co.uk/EDS !reference EP_EDS_ECMA_149/112 !date 1094-01-10 !clause Part 1/19.3.9 !priority medium !title Insufficient checks to prevent graph cycles !comment 19.3.9 USER_GROUP_ADD_SUBGROUP Consider the case of groups as follows: ALL_USERS -> A -> B -> C -> D Where the arrow means 'lhs is a supergroup of rhs' Lets have 'B and C' in one partition and 'A and D' in another. If USER_GROUP_ADD_SUBGROUP(B, C) and USER_GROUP_ADD_SUBGROUP(D, A) are called from their respective partitions then 19.3.9 only allows access errors failures on the immediate pair of groups but the second call should fail with an invalid graph error - this cannot be determined. Proposed resolution: Making read access checks on part of the graph would prevent this problem but still allow cycles to be introduced if 'A and D' were in different replicated sets to 'B and C' with local replicas being present for the other pair in each partition. Then the updates would not detect a graph but a graph would be introduced during the replication update. The simplest way we have to avoid this is to require MODIFY access to the security group directory. This allows the modelling of all security with the directory which eases implementation and is not onerous if there is a single security administrator. !discussion DI-4071/1 !sender Martin Kirby/EDS !date 1995-03-01 The proposed resolution is insufficient in the case of multiple replica sets as described in the original problem. The replicas may be accessible but cyclic graphs could be introduced by concurrent changes to masters on different replicated sets. In practice I think it is better to view the security model as being co-located with the security group directory and therefore to make a check ACCESS_ERRORS (security group directory, ATOMIC, MODIFY, APPEND_IMPLICIT) Arguably, APPEND_IMPLICIT is wrong since what is being changed is the model which is really the contents and APPEND_CONTENTS would be more appropriate? !history Agreed at TGOO-05. Resolution not included in ISO/IEC 13719-1 as too vague. At WG22/1 B.bird agreed to formulat a proposal along more specific lines than DI-4071/1. !resolution TGOO-05: Add implementation-dependent errors for object is inaccessible (some object in the graph of security groups) ------------------------------------------------------------------------ !identifier EP-4128 !status resolved !sender Barry Bird/bdb@sdsph.sdsci.co.uk/EDS !reference EP_EDS_ECMA_149/180 !date 1994-01-10 !clause Part 1/9.3.2 !priority medium !title Replicated objects should not be convertible !comment Error OBJECT_IS_NOT_REPLICABLE C.4(153) lists a number of predefined types, e.g. message_queue, of which instances cannot be made replicated objects. As it stands, OBJECT_CONVERT can be used to make objects of types such as message_queue replicable in contravention of this rule (use REPLICATED_OBJECT_CREATE followed by OBJECT_CONVERT). Therefore OBJECT_CONVERT needs a new error to forbid the operation on objects whose replicated state is not NORMAL. !history Agreed at TGOO-05. Resolution not included in ISO/IEC 13719-1 as too vague. At WG22 it was agreed to add a new error OBJECT_IS_NOT_CONVERTIBLE with specification as in the resolution; J.Dawes agreed to produce wording. !resolution TGOO-05: OBJECT_CONVERT is not permitted if: a) replicated state is not NORMAL, and b) the new type is one of the types forbidden by Part 1/17.1.2(14). WG22/1: add new error OBJECT_IS_NOT_CONVERTIBLE (/object/) to OBJECT_CONVERT. Add error to C.3: OBJECT_IS_NOT_CONVERTIBLE (/object/) The object /object/ cannt have its type converted because its replicated state is not NORMAL, or because it is an object of a type such that it cannot be replicated (see 17.1.2). ------------------------------------------------------------------------ !identifier EP-4227 !status resolved !sender Richard Stuckey/res@win.icl.co.uk !reference EP_ICL_ECMA_158/001 !date 1994-02-16 !clause Part 2/8.2.5 !priority high !title Pcte_time almost unusable !comment Paragraph (5) effectively makes the type Pcte_time a private type; however, the functions described are NOT provided by the Binding, thus making it impossible to set attributes to 'real' dates, or to read attribute values as 'real' dates. The definition of type Pcte_time as the type time_t is in itself somewhat suspect, as it has implications that the values are actually encoded as the number of seconds from some reference point, and hence that the standard C library functions timegm, gmtime, etc., may be used to manipulate values of this type. However, if this approach is used, a problem arises. The C/UNIX reference time is 1970-01-01T00:00:00Z (UTC), defined as a time_t value of 0, whereas the PCTE reference time is 1980-01-01T00:00:00Z, defined as the implementation-defined constant Pcte_reference_time. This means that if Pcte_times are converted into C times (by addition/subtraction of a suitable bias) so that the standard C functions can be used, the latest date which can be handled (given the use of 32-bit ints by C) is 1970-01-01T00:00:00Z + 2 ** 31 - 1 seconds which is 2038-01-19T03:14:07Z. This date is earlier than MAX_TIME_ATTRIBUTE, which is defined as being no earlier than 2044-12-31T24:00:00Z. Suggested resolution: make Pcte_time an implementation-defined type, and provide a set of operations upon it, comparable to those provided by the Ada Binding package PCTE.CALENDAR. The PCTE user should not be required to worry about the trivia (e.g. leap years, leap seconds, etc.) of converting between 'real' dates and Pcte_time values. !history Agreed at TGOO-05. Resolution not included in ISO/IEC 13719-2 as insufficiently worked out. At WG22/1 it was agreed to reject this proposed change. !resolution TGOO-05: There is a need to define a new set of C routines analogous to PCTE.CALENDAR: Pcte_time is a C unsigned integer type in the range MIN_TIME_ATTRIBUTE to MAX_TIME_ATTRIBUTE with operations year, month, day, seconds, split, time_of. Being integer, the +, - and == operations are automatically available. This needs to be finalised. WG22/1: No change required. ------------------------------------------------------------------------ !identifier EP-4310 !status resolved !sender JTC1 Japan !reference JTC1_Japan !date 1994-03-16 !clause Part 1/Appendix A.1 !priority high !title Multi-octet character set !comment There is no clear definition on multi-octet character set referred to in the DIS. Japan has a national standard on 7-bit 2-bytescoded character set for Kanji characters and also is going to have another national standard based on ISO/IEC 10646-1. We urge the DIS to have a capability to accept both standards stated above. The Japanese National Body is ready to submit a proposal for amendment if necessary. !discussion DI-4310/1 !sender Barry Bird/EDS !date 1995-03-24 Discussion on part 2 of comment. This is written not from the perspective of an expert in multi-byte character sets. >From 23.1.2.4: (2) link name = cardinality one link name | cardinality many link name; (3) cardinality one link name = '.', link type name; (4) cardinality many link name = key, '.', [ link type name ] | key; Link name (also known as link reference) can occur in a pathname. Paragraph (4) causes problems for a simple parsing, since type names cannot always be distinguished from key string values, but can be handled. The important point to note, however, is the mixing of keys and type names. Replacement for 23.1.3.2(3) must exclude both minus and underscore from name first character due to possible confusion with type identifiers. It is not clear why * and ) are also proposed to be excluded. Character exclusions proposed are (with the addition above): $ # ~ _ + . - / * ( ) first key char X X X X X X X X first name char X X X X X X X X X other key char X X X other name char X X X The three characters * ( ) prevent a simple hierarchy of character scope. We need to be clear on support for multiple character sets. Is it possible for an implementation to support both a single byte character set and a multi-byte character set? It seems to us that the result is potentially confused unless keys and names are marked in some implementation-dependent way with the char set that they employ. For example, it seems that the kana OVERLINE character can be confused with the tilde character. The necessity for the tilde character ("home_object") is probably slight, however. !history There was some correspondance on this issue shortly before production of the final draft of ECMA-149 version 2 for fast-track processing; the only change to ECMA-149 as a result was the addition of a commentary to 23.1.1.6: 'It is not intended to exclude the use of coded character sets other than ISO 8859-1, including multi-octet character sets; it is therefore not assumed that one octet corresponds to one graphic character.'. J.Dawes expressed the hope that the issue could be resolved during the fast-track process when ISO expertise would be available. At the SC22 Ballot Resolution Meeting the Japanese delegation proposed a resolution in 2 parts: (1) 23.1.1.6 Extend the definition of 'octet' to make it possible to handle multi-byte character sets. (2) 23.1.3.2 Change definition of 'name' and add definition of 'character'. (1) was agreed with some wording changes, see 'resolution' below, and the resolution to part (1) was included in ISO/IEC 13719-1. (2) was deferred as it was felt there was insufficient time to work out the ramifications; SC22 was requested to deal with it as a matter of high priority. A draft proposed resolution was prepared by J.Dawes as a basis for discussion. At WG22/1 there was further discussion on part (2) resulting in the final resolution shown below. It was noted that there remained two problems: - How to identify the character set used in operations such as LINK_CREATE. This was deferred; M.Yoshino, K.Simonsen, and B.Bird agreed to pursue the matter by e-mail. - Representation of national characters (i.e outside the ISO 646 invariant subset). J.Dawes agreed to prepare one or more draft proposals. !resolution Part (1): - Part 1/23.1.1.6. Change the heading to: 'OCTET, Character, and Text Values'. - Part 1/23.1.1.6(2-4). Replace these paragraphs by the following: (2) Octet values have no intrinsic graphical representation. When a graphical representation is required, the graphical representation of the PCTE datatype Character is used. (3) The PCTE datatype Character comprises the human-readable characters of one or more character sets selected by the PCTE implementation. In a character set, a single character may be represented by a single byte or by more than one byte. (4) The PCTE Datatype Text comprises sequences of characters. Characters of more than one character set may exist in a single text value. The method of identifying the character set of a given character is implementation-defined. NOTES (5) 1. By the definition of the PCTE datatype Character, an octet may be part of a character of a multi-byte character set. Therefore, it may occur that an octet which is identical to an octet associated with a character of a single-byte character set is part of a character of a multi-byte character set. Even if such an octet is identical to an octet associated with a special character (e.g. '/', '$', '#', '.' in a pathname), a PCTE implementation should not interpret the octet as such a special character. (6) 2. For the definitions of the terms 'octet' and 'character set' see ISO/IEC 10646-1. For the definition of the term 'byte' see ISO/IEC 2022. Part (2): - Replace 23.1.3.2(2-5) by the following: (2) name = name first character, { name character }; (3) name first character = name character - ('/', '$', '#', '-', '_', '.', '~', '*', '('); (4) name character = character - ('/', '$', '#', '-', '~', ')'); - Replace B.7(8,9) by the following: (8) sds name = name; (9) local name = name; - In B.7 add a new paragraph after (10): (10A) name = identifier | ' " ', character, { character }, ' " '; - In B.7 add a new paragraph after (18) (under 'Constraints'): (18A) The sequence of characters of a name of the second form must respect the syntax of names in 23.1.3.2. ------------------------------------------------------------------------ !identifier EP-4346 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (3.1.1) !date 1994-02-24 !clause Part 1/10.2.1 !priority medium !title sds_add_destination !comment The operation also checks the following error: if link_type has a reverse link type: ACCESS_ERRORS (reverse_link_type, ATOMIC, WRITE, APPEND_LINKS). !history Raised too late for consideration at the Ballot Resolution Meeting. Recommendation accepted at WG22/1. !resolution Add to Part 1/10.2.1: ACCESS_ERRORS (/reverse_link_type_in_sds/, ATOMIC, MODIFY, APPEND_LINKS) ------------------------------------------------------------------------ !identifier EP-4347 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (3.1.2) !date 1994-02-24 !clause Part 1/10.2.2 !priority medium !title sds_apply_attribute_type !comment [1] The key attribute types of a link type are considered as applied to the link type; therefore the error TYPE_IS_ALREADY_APPLIED is also raised if an attempt is made to apply an attribute type to a link type if that attribute type is a key attribute type of the link type. [2] The error LINK_TYPE_CATEGORY_IS_BAD is raised if type designates a link type of category IMPLICIT. !discussion DI-4347/1 !sender Barry Bird/EDS !date 1994-05-24 Disagree in part. [1] The key attribute types are not applied attribute types. See 8.5.3(1). This is confirmed by the resolution of EP-4119. Therefore there is no problem if the same attribute type is both a key attribute and a non-key attribute. [2] Add error to 10.2.2: LINK_TYPE_CATEGORY_IS_BAD(/link_type/, (COMPOSITION, EXISTENCE, REFERENCE, DESIGNATION)) Rationale: implicit links may not have non-key attributes. !discussion DI-4347/2 !sender Udo Kelter, U. Siegen !date 1995-01-23 [1] Intuitively, I do not like the idea that key attribute types of a link types are not applied ones, and that the same attribute can appear twice at a link, namely both as a key and a non-key attribute. - This is in sharp contrast with the basic notion of an attribute in the rest of the world. - It makes the whole concept of a key being composed of a sequence of attribute values really pointless. There would be no longer any justification for all the complications involved with the handling of key attributes (representation in the metabase, implicit imports etc.) if I could not read key attributes with LINK_GET_ATTRIBUTE like normal attributes. We could have simply defined a key to be a string, maybe with a specific syntax, and the evaluation of ++ etc. in that context. - I would even go one step further and say that, in the future, key attributes should really be normal attributes in the sense that they can be updated. I have never understood why this was not allowed. Virtually everybody who has ever implemented PCTE applications working on reasonably fine-grained data complains about the lack of this operation. This operation is NOT implementable on top of the API. Within the kernel, an implementation is really simple. The only extension is an additional error code for LINK_SET_ATTRIBUTE saying that the resulting key already exists. !discussion DI-4347/3 !sender Martin Kirby/EDS !date 1995-03-01 There remain inconsistencies in this area. Key attributes cannot be got using link_get_attribute but there is no error for the case where they have been applied and key attribute unapply is forbidden which is inconsistent with allowing application. There seem to be two consistent resolutions and there seems little to choose between them: a) SDS_APPLY_ATTRIBUTE_TYPE add a new error KEY_ATTRIBUTE_TYPE_APPPLY_IS_FORBIDDEN SDS_UNAPPLY_ATTRIBUTE_TYPE remove error KEY_ATTRIBUTE_TYPE_UNAPPPLY_IS_FORBIDDEN Key attributes are not applied, cannot be applied and therefore getting the attribute would always fail with attribute is not applied errors. b) SDS_APPLY_ATTRIBUTE_TYPE add a note that key attributes are initially not applied but can be applied. SDS_UNAPPLY_ATTRIBUTE_TYPE remove error KEY_ATTRIBUTE_TYPE_UNAPPPLY_IS_FORBIDDEN Change LINK_GET_ATTRIBUTE/LINK_GET_SEVERAL_ATTRIBUTES to return any applied attribute, i.e. including key attributes if they have been applied --- In either case LINK_DELETE_ATTRIBUTE needs error KEY_UPDATE_IS_FORBIDDEN !discussion DI-4347/4 !sender Udo Kelter/University of Siegen !date 1995-03-11 I would strongly argue in favour of solution b). Solution a) makes the whole concept of key attributes (all resulting further complications) completely pointless since key attributes become completely different from normal attributes. >In either case LINK_DELETE_ATTRIBUTE needs error KEY_UPDATE_IS_FORBIDDEN To be consistent with the current situation, this error must in fact be introduced. However, I would argue that the error KEY_UPDATE_IS_FORBIDDEN should be removed completely . The ability to modify key attributes easy and efficiently is desparately needed. (I think the lack of this feature was mentioned in 3 or 4 presentations at the PCTE 94 conference). It CANNOT be generally implemented on top of the PCTE API, but easily within the kernel. I do not know of a good reason why it is not allowed. The argument that key attributed must be dealt with differently from other attributes is not valid; they need anyway a special treatment. !recommend [1] No change. [2] Accept DI-4347/1 part [2]. !history Raised too late for consideration at the Ballot Resolution Meeting. At WG22/1 the recommendation for part [2] was accepted. On part [1] it was agreed that an attribute type could not be used as both a key type and a non-key type for the same link type, i.e. (a) of DI-4347/3; J.Dawes offered to write up a recommendation. ------------------------------------------------------------------------ !identifier EP-4348 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (3.1.3) !date 1994-02-24 !clause Part 1/10.2.5 !priority medium !title sds_create_designation_link_type !comment [1] The error LIMIT_WOULD_BE_EXCEEDED is raised when too much key_types are provided. [2] The error PCTE_LINK_TYPE_CATEGORY_IS_BAD is raised when the link to be created is not of category DESIGNATION. !discussion DI-4348/1 !sender Barry Bird/EDS !date 1994-05-24 Disagree. [1] There is no limit and has been no limit to the number of key attributes that can be defined for a link. [2] No parameter specifies the category, since it is implied by the operation name. !history Raised too late for consideration at the Ballot Resolution Meeting. Recommendation accepted at WG22/1. !resolution No change. ------------------------------------------------------------------------ !identifier EP-4349 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (3.1.4) !date 1994-02-24 !clause Part 1/10.2.7 !priority medium !title sds_create_enumeration_attribute_type !comment [1] The error VALUE_IS_OUT_OF_RANGE is raised if initial_value is out of the range specified by values. [2] The error NO_ENUMERALS is raised when no enumeral is specified. [3] The error TYPE_IS_UNKNOWN_IN_SDS is raised if one of the specified enumeral types is not defined in the SDS. [4] The operation also checks the following errors for each specified enumeral type: ACCESS_ERRORS(enumeral_type, ATOMIC, CHANGE, APPEND_IMPLICIT) ACCESS_ERRORS(enumeral_type_in_sds, ATOMIC, CHANGE, READ_ATTRIBUTE). !discussion DI-4349/1 !sender Barry Bird/EDS !date 1994-05-24 [1] Add to 10.2.7: ENUMERATION_VALUE_IS_OUT_OF_RANGE(/initial_value/, /values/) Add to C.4: ENUMERATION_VALUE_IS_OUT_OF_RANGE(/initial_value/, /values/) The value given by /initial_value/ is outside of the range of positions defined by the sequence of enumerals /values/. [2] NO_ENUMERALS: See my resolution of EP-4401. [3] Add to 10.2.7: TYPE_IS_UNKNOWN_IN_SDS(/sds/, element of /values/) [4] I do not see the need for the first proposed ACCESS_ERRORS which is already covered by para (13). The second should be: For each enumeral_type_in_sds object E corresponding to an enumeral type in /values/, ACCESS_ERRORS(E, ATOMIC, READ, READ_ATTRIBUTES) !history Raised too late for consideration at the Ballot Resolution Meeting. Recommendation accepted at WG22/1. !resolution [1] Accept DI-4349/1 part [1]. [2] Covered by EP-4401 (see below). [3] Accept DI-4349/1 part [3]. [4] Accept DI-4349/1 part [4]; add to Part 1/10.2.7: For each enumeral_type_in_sds object E associated with an element of /values/: ACCESS_ERRORS (E, ATOMIC, READ, READ_ATTRIBUTES) ------------------------------------------------------------------------ !identifier EP-4350 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (3.1.5) !date 1994-02-24 !clause Part 1/10.2.11 !priority medium !title sds_create_object_type !comment - The error NO_PARENTS is raised when no parent is specified - The error PARENT_TYPES_ARE_MULTIPLE is raised when a parent type occurs more than once in types. !discussion DI-4350/1 !sender Barry Bird/EDS !date 1994-05-24 Covered by EP-4025 and EP-4401. !history Raised too late for consideration at the Ballot Resolution Meeting. At WG22/1 DI-4350/1 was agreed; resolution was deferred until EP-4401 had been addressed. (EP-4025 is implemented in ISO/IEC 13719.) ------------------------------------------------------------------------ !identifier EP-4351 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (3.1.6) !date 1994-02-24 !clause Part 1/10.2.12 !priority medium !title sds_create_relationship_type !comment - The error LIMIT_WOULD_BE_EXCEEDED is raised when too much key_types are provided. !discussion DI-4351/1 !sender Barry Bird/EDS !date 1994-05-24 Disagree. There is no limit and has been no limit to the number of key attributes that can be defined for a link. (There is an effective limit implied by other constraints, but no explicit limit.) !history Raised too late for consideration at the Ballot Resolution Meeting. Recommendation accepted at WG22/1. !resolution No change. ------------------------------------------------------------------------ !identifier EP-4352 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (3.1.7) !date 1994-02-24 !clause Part 1/10.2.16 !priority medium !title sds_import_attribute_type !comment [1] The READ access mode is checked (instead of MODIFY) on the type_in_sds object associated with type in from_sds. [2] If type is an enumeration attribute type, the access error ACCESS_ERRORS (type_in_sds, ATOMIC, READ, EXPLOIT_SCHEMA) is checked on each enumeral_type_in_sds object associated with the enumeral types of type in from_sds. !discussion DI-4352/1 !sender Barry Bird/EDS !date 1994-05-24 [1] Same as EP-4123. [2] Add to 10.2.16: If /type/ is an enumeration attribute type, for each enumeral_type_in_sds object S associated with /type/ in /from_sds/: ACCESS_ERRORS(S, ATOMIC, READ, EXPLOIT_SCHEMA) !history Raised too late for consideration at the Ballot Resolution Meeting. Recommendation accepted at WG22/1. !resolution [1] Covered by EP-4123 (implemented in ISO/IEC 13719). [2] Accept DI-4352/1 part [2]. ------------------------------------------------------------------------ !identifier EP-4353 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (3.1.8) !date 1994-02-24 !clause Part 1/10.2.18 !priority medium !title sds_import_link_type [1] The READ access mode is checked (instead of MODIFY) on the type_in_sds object associated with type in from_sds. [2] The access error ACCESS_ERRORS(type_in_sds, ATOMIC, READ, EXPLOIT_SCHEMA) is checked on each attribute_type_in_sds object associated with the key attribute types of type in from_sds. !discussion DI-4353/1 !sender Barry Bird/EDS !date 1994-05-24 [1] Same as EP-4124. [2] Add to 10.2.18: For each attribute_type_in_sds object A associated with a key attribute type of /type/: ACCESS_ERRORS(A, ATOMIC, READ, EXPLOIT_SCHEMA) !history Raised too late for consideration at the Ballot Resolution Meeting. Recommendation accepted at WG22/1. !resolution [1] Covered by EP-4124 (implemented in ISO/IEC 13719). [2] Accept DI-4353/1 part [2]. ------------------------------------------------------------------------ !identifier EP-4354 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (3.1.9) !date 1994-02-24 !clause Part 1/10.2.19 !priority medium !title sds_import_object_type !comment [1] The missing ACCESS_ERRORS on from_sds, to_sds, the type in sds and the imported type have been implemented as for sds_import_link_type. [2] The access error ACCESS_ERRORS(type_in_sds, ATOMIC, READ, EXPLOIT_SCHEMA) is checked on each object_type_in_sds object associated with the parent types of type in from_sds. !discussion DI-4354/1 !sender Barry Bird/EDS !date 1994-05-24 [1] Covered by EP-4067. [2] Add to 10.2.19: For each object_type_in_sds object S associated with the ancestor types of /type/: ACCESS_ERRORS(S, ATOMIC, READ, EXPLOIT_SCHEMA) !history Raised too late for consideration at the Ballot Resolution Meeting. Recommendation accepted at WG22/1. !resolution [1] Covered by EP-4067 (implemented in ISO/IEC 13719). [2] Accept DI-4354/1[2]. ------------------------------------------------------------------------ !identifier EP-4355 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (3.1.10) !date 1994-02-24 !clause Part 1/10.2.20 !priority medium !title sds_initialise !comment The ACCESS_ERRORS on the SDS object is implemented as: ACCESS_ERRORS(sds, ATOMIC, WRITE, APPEND_IMPLICIT). !discussion DI-4355/1 !sender Barry Bird/EDS !date 1994-05-24 Replace 10.2.20 by: ACCESS_ERRORS (/sds/, ATOMIC, CHANGE, APPEND_IMPLICIT) !history Raised too late for consideration at the Ballot Resolution Meeting. Recommendation accepted at WG22/1. !resolution Accept DI-4355/1. ------------------------------------------------------------------------ !identifier EP-4356 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (3.1.11) !date 1994-02-24 !clause Part 1/10.2.21 !priority medium !title sds_remove !comment The access error on the SDS is implemented as: ACCESS_ERRORS(sds, ATOMIC, WRITE, (DELETE | WRITE_IMPLICIT)). !discussion DI-4356/1 !sender Barry Bird/EDS !date 1994-05-24 Replace 10.2.21(6) by: ACCESS_ERRORS (/sds/, ATOMIC, CHANGE, WRITE_IMPLICIT) If the conditions hold for deletion of the "sds" object /sds/: ACCESS_ERRORS (/sds/, COMPOSITE, MODIFY, DELETE) !history Raised too late for consideration at the Ballot Resolution Meeting. Recommendation accepted at WG22/1. !resolution Accept DI-4356/1. ------------------------------------------------------------------------ !identifier EP-4357 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (3.1.12) !date 1994-02-24 !clause Part 1/10.2.23 !priority medium !title sds_remove_type !comment [1] All access errors are implemented with a scope ATOMIC. [2] If the type object is to be actually deleted, no security checks are performed on the related type objects (i.e. the parent types in case of a deleted object type, the key attribute types in case of a deleted link type and the enumeral types in case of an enumeration attribute type. !discussion DI-4357/1 !sender Barry Bird/EDS !date 1994-05-24 Disagree. [1] The implementation is wrong here. DELETE is a composite permission. [2] Again, these security checks should be observed. !history Raised too late for consideration at the Ballot Resolution Meeting. Recommendation accepted at WG22/1. !resolution No change. ------------------------------------------------------------------------ !identifier EP-4358 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (3.2) !date 1994-02-24 !clause Part 1/10 !priority medium !title SDS Usage Operations !comment The sds_xxx functions return full type name instead of a local name in output parameters. The sds_xxx functions accept full type names as input parameters provided that the SDS name part of the full type names designates the same SDS than the "sds" parameter. !discussion DI-4358/1 !sender Barry Bird/EDS !date 1994-05-24 This again is an implementation issue and does not affect the standard. !history Raised too late for consideration at the Ballot Resolution Meeting. Recommendation accepted at WG22/1. !resolution No change. ------------------------------------------------------------------------ !identifier EP-4359 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (4.1.1) !date 1994-02-24 !clause Part 1/11.2.6 !priority medium !title device_remove !comment The operation may also return the following errors, if the designated device is to be deleted: for each origin X of an implicit link to device: ACCESS_ERRORS(X, ATOMIC, CHANGE, WRITE_IMPLICIT), for each compositely stabilising link L from device: ACCESS_ERRORS(destination of L, COMPOSITE,CHANGE). !discussion DI-4359/1 !sender Barry Bird/EDS !date 1994-05-24 This is at variance with OBJECT_DELETE and needs more consideration. !discussion DI-4359/2 !sender JeanClaude.Grosselin/Emeraude !date 1994-06-06 First of all, the DEVICE_REMOVE operation works like LINK_DELETE (and not OBJECT_DELETE since no composite object deletion), in this case the two missing errors are defined for LINK_DELETE and so have to be added to DEVICE_REMOVE (and this is consistent). I think that Barry find the proposed resolution not consistent with OBJECT_DELETE because the two errors are not mentionned in the specification of OBJECT_DELETE. For me, these errors are missing and have also to be added (This makes consistent both LINK_DELETE, OBJECT_DELETE and DEVICE_REMOVE). So add to OBJECT_DELETE the two errors: For each implicit incoming external link L to a deleted object: ACCESS_ERRORS(origin of L , ATOMIC, CHANGE, WRITE_IMPLICIT) For each compositely stabilizing outgoing external link L of a deleted object: ACCESS_ERRORS(destination of L, COMPOSITE, CHANGE) ==> Note for the reader : compositely stabilizing outgoing link L are only reference links !discussion DI-4359/3 !sender Martin Kirby/EDS !date 1995-03-01 The change based on compositely stabilizing outgoing external links should require STABILIZE permission as with any other link deletion. Also there should be ATOMIC, CHANGE, STABILIZE check for atomically stabilizing outgoing links. !recommend (1) Add these two errors to Part 1/11.2.6: For each origin X of an implicit link to /device/: ACCESS_ERRORS(X, ATOMIC, CHANGE, WRITE_IMPLICIT) For each compositely stabilizing link L from /device/: ACCESS_ERRORS(destination of L, COMPOSITE, CHANGE) (2) Add these two errors to Part 1/9.3.5: For each implicit incoming external link L to a deleted object: ACCESS_ERRORS (origin of L, ATOMIC, CHANGE, WRITE_IMPLICIT) For each compositely stabilising external link L of a deleted object: ACCESS_ERRORS (destination of L, COMPOSITE,CHANGE) !history Raised too late for consideration at the Ballot Resolution Meeting. At WG22/1 it was accepted, J.Dawes agreed to attempt to progress further towards a solution. ------------------------------------------------------------------------ !identifier EP-4360 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (4.1.2) !date 1994-02-24 !clause Part 1/11.2.11 !priority medium !title volume_mount !comment The access error on the volume object is implemented as: ACCESS_ERRORS(volume, ATOMIC, READ, NAVIGATE) (otherwise it would not be possible to mount read-only volumes). !discussion DI-4360/1 !sender Barry Bird/EDS !date 1994-05-24 Replace in 11.2.11(7) 'MODIFY, APPEND_LINKS' by 'READ, NAVIGATE'. !history Raised too late for consideration at the Ballot Resolution Meeting. Recommendation accepted at WG22/1. !resolution Accept DI-4360/1. ------------------------------------------------------------------------ !identifier EP-4361 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (4.1.3) !date 1994-02-24 !clause Part 1/11.2.12 !priority medium !title volume_unmount !comment The access error on the volume object is implemented as: ACCESS_ERRORS(volume, ATOMIC, READ, NAVIGATE) (otherwise it would not be possible to unmount read-only volumes). !discussion DI-4361/1 !sender Barry Bird/EDS !date 1994-05-24 Replace in 11.2.12(6) 'MODIFY, WRITE_LINKS' by 'READ, NAVIGATE'. !history Raised too late for consideration at the Ballot Resolution Meeting. Recommendation accepted at WG22/1. !resolution Accept DI-4361/1. ------------------------------------------------------------------------ !identifier EP-4362 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (5.1) !date 1994-02-24 !clause Part 1/12.1 !priority medium !title Files, Pipes, Devices Operations !comment [1] The opening modes of open objects links keyed by 0, 1 and 2 are not forced to READ_ONLY, respectively APPEND_ONLY, APPEND_ONLY (i.e. no check is made in contents_open to enforce that). [2] The error CONTENTS_OPERATION_IS_INVALID can be returned in cases where the opened contents designated by contents_handle has a positioning mode that does not allow the current operation to be performed. !discussion DI-4362/1 !sender Barry Bird/EDS !date 1994-05-24 [1] Agreed. In 12.1(56) delete 'has READ_ONLY opening mode and'. In 12.1(57) delete 'has APPEND_ONLY opening mode and'. In 12.1(58) delete 'has APPEND_ONLY opening mode and'. [2] Agreed. Insert into C.4(31), 'or positioning' after 'opening mode'. !discussion DI-4362/2 !sender John Dawes/ICL !date 1994-06-24 [1] 12.1(56-58) are now so short they can be combined: 'The "open_object" links keyed by 0, 1, and 2 are called /standard input/, /standard output/, and /standard error/ respectively.' !discussion DI-4362/3 !sender Martin Kirby/EDS !date 1995-03-01 With the change in DI-4362/2 [1] I think the open objects 0, 1, and 2 do not differ from any other open object so identifying them with particular names in a standard seems fruitless (Especially since standard output could be read-only which would be confusing). Suggest dropping the paragraphs 12.1(56- 58) completely. !history Raised too late for consideration at the Ballot Resolution Meeting. At WG22/1 DI-4362/1[2] was accepted, and DI-4362/2[1] with the further change to merge 12.1(56-58) into 12.1(61) (as 12.1(56-58) no longer contain normative information). DI-4362/3 was rejected as it was felt the names were still useful. !resolution [1] Delete 12.1(56-58); replace 12.1(61) (under NOTES) by: '1. The "open_object" links keyed by 0, 1, and 2 are called /standard input/, /standard output/, and /standard error/ respectively. Conventionally, standard input is used by the process for the reading of commands or input data, standard output is used for the output of data, and standard error is used for the output of error diagnostics.' [2] Accept DI-4362/1 part [2]. ------------------------------------------------------------------------ !identifier EP-4363 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (5.1.1) !date 1994-02-24 !clause Part 1/12.2.6 !priority medium !title contents_open !comment [1] The positioning mode of the object is not set to SEQUENTIAL (default value of the attribute = SEEK). [2] The operation may also return the following error: STATIC_CONTEXT_IS_IN_USE. [3] The error NON_BLOCKING_IO_IS_INVALID is always returned when attempting to open files in non-blocking mode, and never when attempting to open devices in non-blocking mode. !discussion DI-4363/1 !sender Barry Bird/EDS !date 1994-05-24 [1] 12.2.6(5) positioning SEQUENTIAL: I think that this should be the default since it is likely to be the most common mode of access. [2] Static contexts: See EP-4125. [3] change the text of C.4(125) to: An attempt is being made to open an object /object/ of type "file" with /non_blocking_io/ |false|, or to open an object /object/ of type "pipe" or "device" with /non_blocking_io/ |true| when it does not support non-blocking input-output. !discussion DI-4363/2 !sender Martin Kirby/EDS !date 1995-03-01 Re recommendation [1] I do not understand the recommendation. Opening a file should not change its positioning. Is the change intended to be against 12.1(14) !history Raised too late for consideration at the Ballot Resolution Meeting. At WG22/1 the recommendation was accepted. !resolution [1] Accept DI-4363/1[1]. [2] Covered by EP-4125 (implemented in ISO/IEC 13719). [3] Accept DI-4363/1[3]. ------------------------------------------------------------------------ !identifier EP-4364 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (5.1.2) !date 1994-02-24 !clause Part 1/12.2.7 !priority medium !title contents_read !comment When there is no data to read on a pipe opened in any mode (blocking or not) and that pipe is not currently opened for writing by any process, an empty data sequence is returned. !discussion DI-4364/1 !sender Barry Bird/EDS !date 1994-05-24 Needs more explanation. !discussion DI-4364/2 !sender Barry Bird/EDS !date 1994-06-09 The reasons for making this change have not been stated. Can the proposers please give their reasons ? Summary of present situation for reading contents when there is no data: file pipe pipe device device non-block non-block block non-block block read - no data returns null fail wait fail wait The failure is DATA_ARE_NOT_AVAILABLE. My understanding is: There is a usability problem when the writing process has terminated abnormally. PCTE will close the pipe, but the process has no opportunity to send some indication of termination to the reader. How can the reader know not to keep trying to read the pipe apart from examining the "open_object" links? This is really an error situation and so attempting to read a blocking or non- blocking pipe should give rise to an error when no writer has the pipe opened: PIPE_HAS_NO_WRITERS(contents) An attempt has been made to read pipe /contents/ and either no contents handle was open in APPEND_ONLY mode when the operation was called or the last such handle was closed while this operation was waiting for data to become available. !discussion DI-4364/3 !sender Martin Kirby/EDS !date 1995-03-01 Deleting the contents of a pipe when the writer terminates seems completely wrong to me. Typical use of a pipe can be for a feeder process to write data to it and a reader process to consume it. The feeder will normally terminate whilst the consumer is still working. The consumer should then read the last data sent and get a message at that time that there is no data and no likelihood of more data! So add PIPE_HAS_NO_WRITERS error for when there is no data available and no contents handle is open on the pipe in APPEND_ONLY mode (or the last one closed whilst waiting). Note that this doesn't count READY processes that have inherited a contents handle on the pipe as having it open - this feels correct to me but I'm not sure. !recommend Add after Part 1/12.2.7(8) as an additional dashed item: - if /contents/ is a pipe and that pipe is not currently opened for writing by any process, /data/ is reset to the empty sequence. !history Raised too late for consideration at the Ballot Resolution Meeting. At WG22/1 a resolution was agreed but the Project Editor neglected to note what it was. ------------------------------------------------------------------------ !identifier EP-4365 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (5.1.3) !date 1994-02-24 !clause Part 1/12.2.8 !priority medium !title contents_seek !comment The operation may also return the following error: OBJECT_IS_INACCESSIBLE. !discussion DI-4365/1 !sender Barry Bird/EDS !date 1994-05-24 Add to 12.2.8: OBJECT_IS_INACCESSIBLE(object determined by /contents/, ATOMIC) !history Raised too late for consideration at the Ballot Resolution Meeting. At WG22/1 the recommendation was accepted. !resolution Accept DI-4365/1. ------------------------------------------------------------------------ !identifier EP-4366 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (5.1.4) !date 1994-02-24 !clause Part 1/12.2.9 !priority medium !title contents_set_position !comment The operation may also return the following error: OBJECT_IS_INACCESSIBLE. !discussion DI-4366/1 !sender Barry Bird/EDS !date 1994-05-24 Add to 12.2.9: OBJECT_IS_INACCESSIBLE(object determined by /contents/, ATOMIC) !history Raised too late for consideration at the Ballot Resolution Meeting. At WG22/1 the recommendation was accepted. !resolution Accept DI-4366/1. ------------------------------------------------------------------------ !identifier EP-4367 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (5.1.5) !date 1994-02-24 !clause Part 1/12.2.10 !priority medium !title contents_set_properties !comment The operation may also return the following error: OBJECT_IS_INACCESSIBLE. !discussion DI-4367/1 !sender Barry Bird/EDS !date 1994-05-24 Add to 12.2.10: OBJECT_IS_INACCESSIBLE(object determined by /contents/, ATOMIC) !history Raised too late for consideration at the Ballot Resolution Meeting. At WG22/1 the recommendation was accepted. !resolution Accept DI-4367/1. ------------------------------------------------------------------------ !identifier EP-4368 !status resolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (5.1.6) !date 1994-02-24 !clause Part 1/12.12 !priority medium !title contents_write !comment When writing to files, if the maximum process file size would be exceeded, the error LIMIT_WOULD_BE_EXCEEDED is returned if no data can be written. !discussion DI-4368/1 !sender Barry Bird/EDS !date 1994-05-24 Add to 12.2.12: If /contents/ is a file, PROCESS_FILE_SIZE_LIMIT_WOULD_BE_EXCEEDED(/data/, /contents/) Add to C.4: PROCESS_FILE_SIZE_LIMIT_WOULD_BE_EXCEEDED(/data/, /contents/) The writing of /data/ to the file /contents/ would cause /contents/ to exceed the process file size limit for the calling process. [Aside: note that shared current positions mean that one process could be stopped writing to the file by this limit but the other may not.] !history Raised too late for consideration at the Ballot Resolution Meeting. At WG22/1 the recommendation was accepted. !resolution Accept DI-4368/1. ------------------------------------------------------------------------ !identifier EP-4369 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.2.1) !date 1994-02-24 !clause Part 1/13.2.1 !priority medium !title process_create !comment [1] The access errors on the static context (and on the interpreter if any) are implemented as follows: ACCESS_ERRORS(static_context, ATOMIC, READ, EXECUTE). [2] The operation does not check that the limits MAX_PROCESSES_PER_USER and MAX_PROCESSES are not exceeded. !discussion DI-4369/1 !sender Hugh Davis/ICL !date 1994-05-09 I hope and think that the comment intends to say that MAX_PROCESSES_PER_USER and MAX_PROCESSES should be checked by PROCESS_CREATE. !discussion DI-4369/2 !sender Barry Bird/EDS !date 1994-05-24 [1] In 13.2.1(41): change 'MODIFY' to 'READ'. In 13.2.1(42): change 'MODIFY' to 'READ'. [2] This is an implementation problem only. !recommend [1] Accept DI-4369/2[1]. [2] No change. !history Raised too late for consideration at the Ballot Resolution Meeting. AT WG22/1 it was felt that further discussion was needed; J.Dawes agreed to record the arguments as a discussion item. ------------------------------------------------------------------------ !identifier EP-4370 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.2.2) !date 1994-02-24 !clause Part 1/13.2.2 !priority medium !title process_create_and_start !comment [1] The access errors on the static context (and on the interpreter if any) are implemented as follows: ACCESS_ERRORS(static_context, ATOMIC, READ, EXECUTE). [2] The same access errors as in process_start (see ECMA 149 and section process_start below) are checked on the destination of the service designation links created on the new process except for the in_working_schema links (i.e. no security checks are made on the SDS, type_in_sds and type objects composing the inherited working schema). !discussion DI-4370/1 !sender Barry Bird/EDS !date 1994-05-24 [1] In 13.2.2(7): change 'MODIFY' to 'READ'. In 13.2.2(8): change 'MODIFY' to 'READ'. [2] Add to 13.2.2: For each open object /object/ which is the destination of an "open_object" link from the calling process: If the link's opening mode attribute is READ_ONLY or READ_WRITE: ACCESS_ERRORS(/object/, ATOMIC, READ, READ_CONTENTS) If the link's opening mode attribute is WRITE_ONLY or READ_WRITE: ACCESS_ERRORS(/object/, ATOMIC, MODIFY, WRITE_CONTENTS) If the link's opening mode attribute is APPEND_ONLY: ACCESS_ERRORS(/object/, ATOMIC, MODIFY, APPEND_CONTENTS) For the activity /activity/ which is the destination of the "started_in_activity" link from the calling process: ACCESS_ERRORS(/activity/, ATOMIC, SYSTEM_ACCESS) For the user /user/ which is the destination of the "user_identity" link from the calling process: ACCESS_ERRORS(/user/, ATOMIC, SYSTEM_ACCESS) For the user group /group/ which is the destination of the "adopted_user_group" link from the calling process: ACCESS_ERRORS(/group/, ATOMIC, SYSTEM_ACCESS) For the consumer group /group/ which is the destination of the "consumer_identity" link from the calling process: ACCESS_ERRORS(/group/, ATOMIC, SYSTEM_ACCESS) In 13.2.2(15), replace /process/ by /new_process/. !discussion DI-4370/2 !sender Martin Kirby/EDS !date 1995-03-01 The access checks to files and sdss need to be done on the basis of the process that is being started not that starting the process. This is because the started process may: a) not have effective program groups which are effective for the calling process b) may have effective additional program groups c) have adopted a different user group d) be started by a user/user group completely unrelated to that of the process e) be in a different place in the activity hierarchy to the caller and therefore have available, or not have available, some of the objects or changes to the objects. Regarding point (e) it might be better that if an access check failed then rather than failing the operation the inherited file was implicitly closed. If checks are made on this basis then the existing errors may be too imprecise for the user to have any reasonable chance of determining why the process cannot be started (because the user needs to inspect the database within the context of the process being started but can't start it). Also, since there is no way to close inherited files (for a ready process) there would be no way for the user to fix the problem. For these reasons it seems better to try a corrective action rather than report an unusable error. See also EP-4372. !recommend [1] Accept DI-4370/1[1]. [2] Accept DI-4370/1[2]. !history Raised too late for consideration at the Ballot Resolution Meeting. Discussed but not resolved at WG22/1. ------------------------------------------------------------------------ !identifier EP-4371 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.2.3) !date 1994-02-24 !clause Part 1/13.2.4 !priority medium !title process_interrupt_operation !comment A process is allowed to interrupt its own PCTE operations (i.e. the operation never returns the error PROCESS_IS_THE_CALLER). !discussion DI-4371/1 !sender Barry Bird/EDS !date 1994-05-24 This is an implementation issue. !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4372 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.2.4) !date 1994-02-24 !clause Part 1/13.2.13 !priority medium !title process_start !comment [1] The access errors on the SDSs destination of the in_working_schema links are implemented as follows: ACCESS_ERRORS(SDS , ATOMIC, SYSTEM_ACCESS, EXPLOIT_SCHEMA) except that, if some links in_working_schema from the processdo no longer have any destination, these links are ignored. [2] The access errors on the objects destination of the open_object links are implemented as follows: If the link's attribute opening_mode is READ_ONLY or READ_WRITE: ACCESS_ERRORS(object, ATOMIC, READ, READ_CONTENTS) If the link's attribute opening_mode is WRITE_ONLY or READ_WRITE: ACCESS_ERRORS(object, ATOMIC, MODIFY, WRITE_CONTENTS) If the link's attribute opening_mode is APPEND_ONLY ACCESS_ERRORS(object, ATOMIC, READ, READ_CONTENTS) [3] The operation also check the following access error: For the process destination of the parent_process link: ACCESS_ERRORS(parent process, ATOMIC, SYSTEM_ACCESS). !discussion DI-4372/1 !sender Barry Bird/EDS !date 1994-05-24 [1] In 13.2.13(20), replace'SYSTEM_ACCESS' by 'SYSTEM_ACCESS, EXPLOIT_SCHEMA' [2] In 13.2.13(22), replace 'ACCESS_ERRORS(/object/, ATOMIC, SYSTEM_ACCESS)' by: 'If the link's opening mode attribute is READ_ONLY or READ_WRITE: ACCESS_ERRORS(/object/, ATOMIC, READ, READ_CONTENTS) If the link's opening mode attribute is WRITE_ONLY or READ_WRITE: ACCESS_ERRORS(/object/, ATOMIC, MODIFY, WRITE_CONTENTS) If the link's opening mode attribute is APPEND_ONLY: ACCESS_ERRORS(/object/, ATOMIC, MODIFY, APPEND_CONTENTS)' [3] Add to 13.2.13: 'For the process /parent/ which is the destination of the 'parent_process' link from /process/: ACCESS_ERRORS(/parent/, ATOMIC, SYSTEM_ACCESS)' !discussion DI-4372/2 !sender John Dawes/ICL !date 1994-06-24 [1] does not make sense - ACCESS_ERRORS with access mode SYSTEM_ACCESS doesn't refer to /permission/ (see C.3.1). I don't understand the wording of the comment: what does 'are implemented' mean here? !discussion DI-4372/3 !sender Martin Kirby/EDS !date 1995-03-01 See DI-4370/2 !recommend [1] None. [2] Accept DI-4372/1[2]. [2] Accept DI-4372/1[3]. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4373 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.2.5) !date 1994-02-24 !clause Part 1/13.2.15 !priority medium !title process_terminate The operation also allows the termination of READY processes; in that case, the only effect of the operation is to change the process status to TERMINATED. !discussion DI-4373/1 !sender Barry Bird/EDS !date 1994-05-24 In 13.2.15(24), change 'RUNNING' to 'READY, RUNNING'. !recommend Accept DI-4373/1. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4374 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.2.6) !date 1994-02-24 !clause Part 1/13.2.17 !priority medium !title process_wait_for_any_child The operation does not check the discretionary permission WRITE_ATTRIBUTES on the terminated child process. !discussion DI-4374/1 !sender Barry Bird/EDS !date 1994-05-24 I don't understand the reason. More explanation needed. !recommend None. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4375 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.2.7) !date 1994-02-24 !clause Part 1/13.2.18 !priority medium !title process_wait_for_child The errors PROCESS_HAS_NOT_GOT_REQUIRED_STATUS (if status of the specified process is READY) and PROCESS_IS_NOT_CHILD (if the specified process is not a child process of the caller) are returned instead of PROCESS_IS_NOT_TERMINABLE_CHILD. !discussion DI-4375/1 !sender Barry Bird/EDS !date 1994-05-24 This seems to be a change of little value. No change. !discussion DI-4375/2 !sender JeanClaude.Grosselin/Emeraude !date 1994-06-06 According to its definition, the error PCTE_IS_NOT_TERMINABLE_CHILD could be replaced by both errors PROCESS_IS_NOT_CHILD and PROCESS_HAS_NOT_GOT_REQUIRED_STATUS. The request have been made only in order to reduce the general number of error codes and I have not more strong argument in favour of its comments (in fact it is not a problem if the comment is rejected). !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4376 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.3.1) !date 1994-02-24 !clause Part 1/13.3.1 !priority medium !title process_adopt_user_group No access is done (and checked) to the security group directory. !discussion DI-4376/1 !sender Barry Bird/EDS !date 1994-05-24 Agreed. Delete 13.3.1(32). !recommend Accept DI-4376/1. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4377 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.3.2) !date 1994-02-24 !clause Part 1/13.3.7 !priority medium !title process_set_user The working schema of the caller is not reset to empty. !discussion DI-4377/1 !sender Barry Bird/EDS !date 1994-05-24 Reject. The resetting of the working schema with process_set_user was agreed by TGEP. !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4378 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.4.1) !date 1994-02-24 !clause Part 1/13.5.1 !priority medium !title process_add_breakpoint The operation checks the discretionary permission WRITE_ATTRIBUTES on the specified child process (instead of WRITE_CONTENTS). !discussion DI-4378/1 !sender Barry Bird/EDS !date 1994-05-24 WRITE_CONTENTS seems correct to me. Reject. !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4379 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.4.2) !date 1994-02-24 !clause Part 1/13.5.2 !priority medium !title process_continue The operation checks the discretionary permission WRITE_ATTRIBUTES on the specified child process (instead of WRITE_CONTENTS). !discussion DI-4379/1 !sender Barry Bird/EDS !date 1994-05-24 WRITE_CONTENTS seems correct to me. Reject. !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4380 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.4.3) !date 1994-02-24 !clause Part 1/13.5.3 !priority medium !title process_peek The operation only accepts a process_data_size equal to sizeof(Pcte_integer); The operation checks the discretionary permission WRITE_ATTRIBUTES on the specified child process (instead of READ_CONTENTS). !discussion DI-4380/1 !sender Barry Bird/EDS !date 1994-05-24 WRITE_CONTENTS seems correct to me. Reject. !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4381 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.4.4) !date 1994-02-24 !clause Part 1/13.5.4 !priority medium !title process_poke The operation only accepts a process_data_size equal to sizeof(Pcte_integer); The operation checks the discretionary permission WRITE_ATTRIBUTES on the specified child process (instead of WRITE_CONTENTS). !discussion DI-4381/1 !sender Barry Bird/EDS !date 1994-05-24 WRITE_CONTENTS seems correct to me. Reject. !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4382 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.4.5) !date 1994-02-24 !clause Part 1/13.5.5 !priority medium !title process_remove_breakpoint The operation checks the discretionary permission WRITE_ATTRIBUTES on the specified child process (instead of WRITE_CONTENTS). !discussion DI-4382/1 !sender Barry Bird/EDS !date 1994-05-24 WRITE_CONTENTS seems correct to me. Reject. !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4383 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.4.6) !date 1994-02-24 !clause Part 1/13.5.6 !priority medium !title process_wait_for_breakpoint The operation returns whenever the specified process is in/reaches the state STOPPED (regardless of why it is in/reaches that state). !discussion DI-4383/1 !sender Barry Bird/EDS !date 1994-05-24 This is what the para (2) says as far as I can see. !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4384 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (6.4.1) !date 1994-02-24 !clause Part 1/14.1 !priority medium !title Message Queue Concepts The position numbers given to messages in message queues are assigned on a per-PCTE server basis in a monotonically increasing way starting from 1 each time the PCTE server is started, i.e. the counter is not persistent across PCTE termination (even if the message queue objects are). !discussion DI-4384/1 !sender Hugh Davis/ICL 'PCTE server' is not defined in the standard. The comment needs to be restated in terms of the specification. I think we just need to add 'At any instant of time,' to the start of sentence 2 in 14.1(15). !discussion DI-4384/2 !sender Barry Bird/EDS !date 1994-05-24 This seems to deal with implementation matters. Message queue contents are not persistent across workstation termination 18.1.6(14). No change. See EP-4086. !recommend Covered by EP-4086 (implemented in ISO/IEC 13719). !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4385 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (7.2.1) !date 1994-02-24 !clause Part 1/14.2.2 !priority medium !title message_peek [1] A read lock of the default mode is established on the queue. [2] The C binding happily hopes that the message pointer will be set to NULL, which is quite difficult to implement in a marginally useful way (such that the caller copy of the pointer would be updated). !discussion DI-4385/1 !sender Barry Bird/EDS !date 1994-05-24 [1] Add to 14.2.2 a new para: 'A read lock of the default mode is obtained on /queue/.' [2] Covered by resolution of EP-4221. !recommend [1] Accept DI-4385/1[1]. [2] Covered by EP-4221 (implemented in ISO/IEC 13719). !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4386 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (7.2.2) !date 1994-02-24 !clause Part 1/14.2.9 !priority medium !title queue_handler_enable The arrival of a message for which a handler is defined does not resume the listening process if it is suspended (it is not clear in the specifications whether it should or not). !discussion DI-4386/1 !sender Barry Bird/EDS !date 1994-05-24 I think it is clear. There is no statement that the process is resumed. The suspension of a thread is different from the suspension of a process. No change. !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4387 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (7.2.3) !date 1994-02-24 !clause Part 1/14.2.11 !priority medium !title queue_restore The operation may also return the error CONTENTS_FORMAT_IS_INVALID, indicating that the contents have not been created by the queue_save operation. !discussion DI-4387/1 !sender Barry Bird/EDS !date 1994-05-24 See EP-4401. !recommend Covered by EP-4401 (see below). !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4388 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (7.2.4) !date 1994-02-24 !clause Part 1/14.2.13 !priority medium !title queue_set_total_space The error LIMIT_WOULD_BE_EXCEEDED is returned if the requested total space is lower than 4 times MAX_MESSAGE_SIZE. !discussion DI-4388/1 !sender Barry Bird/EDS !date 1994-05-24 Append to C.4(122): 'or /total_space/ is less than four times MAX_MESSAGE_SIZE' !recommend Accept DI-4388/1. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4389 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (8.1.1) !date 1994-02-24 !clause Part 1/18.2.2 !priority medium !title workstation_create The security ranges of the created volume, device and workstation are set to the mandatory context of the process. !discussion DI-4389/1 !sender Barry Bird/EDS !date 1994-05-24 This is largely covered already by 18.2.2(12). Insert into 18.2.2 between paras (16) and (17): - the labels of the created workstation are set to the mandatory context of the calling process; !recommend Accept DI-4389/1. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4390 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (8.2.1) !date 1994-02-24 !clause Part 1/18.3.1 !priority medium !title contents_copy_from_foreign_system [1] A read lock of the default mode is obtained on foreign_system. [2] The error FOREIGN_SYSTEM_IS_INACCESSIBLE will never be returned (the operation always returns the error FOREIGN_OBJECT_IS_INACCESSIBLE if the failure is due to a problem with/on the foreign system, whatever the problem is). [3] If the foreign system does not support copy an error FOREIGN_SYSTEM_IS_INVALID is raised. !discussion DI-4390/1 !sender Barry Bird/EDS !date 1994-05-24 [1] Add to 18.3.1(4): 'A read lock of the default mode is obtained on /foreign_system/.' [2] I think this is an implementation-specific point. [3] FOREIGN_OBJECT_IS_INACCESSIBLE can cover failure to copy as well. No change. !recommend [1] Accept DI-4390/1[1]. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4391 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (8.2.2) !date 1994-02-24 !clause Part 1/18.3.2 !priority medium !title contents_copy_to_foreign_system [1] A read lock of the default mode is obtained on foreign_system. [2] The errors FOREIGN_EXECUTION_IMAGE_IS_BEING_EXECUTED and FOREIGN_SYSTEM_IS_INACCESSIBLE will never be returned (the operation always returns the error FOREIGN_OBJECT_IS_INACCESSIBLE if the failure is due to a problem with/on the foreign system, whatever the problem is). [3] If the foreign system does not support copy an error FOREIGN_SYSTEM_IS_INVALID is raised. !discussion DI-4391/1 !sender Barry Bird/EDS !date 1994-05-24 [1] Add to 18.3.2(4): 'A read lock of the default mode is obtained on /foreign_system/.' [2] I think this is an implementation-specific point. [3] FOREIGN_OBJECT_IS_INACCESSIBLE can cover failure to copy as well. No change. !recommend [1] Replace Part 1/18.3.2(4) by: Read locks of the default mode is obtained on /file/ and on /foreign_system/. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4392 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (9.2.1) !date 1994-02-24 !clause Part 1/19.2.1 !priority medium !title group_get_identifier No mandatory or discretionary access control is performed on the directory of security groups. These checks (mandatory read and discretionary READ_LINKS) are done on the group object instead. !discussion DI-4392/1 !sender Barry Bird/EDS !date 1994-05-24 In 19.2.1(3) replace 'directory of security groups' by 'security group object determined by /group/' !recommend Accept DI-4392/1. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4393 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (9.2.2) !date 1994-02-24 !clause Part 1/19.2.4 !priority medium !title object_set_acl_entry All differences in this operation have not been checked, because the specification is very unclear at this time. A preliminary list follows: [1] The error OBJECT_OWNER_VALUE_WOULD_BE_INCONSISTENT_WITH_ATOMIC_ACL can be returned when scope is ATOMIC when there is an inconsistency with OWNER rights on the granule itself on which the change takes place, not only with an outer granule. [2] The error CONTROL_WOULD_NOT_BE_GRANTED can be returned. [3] The discretionary permission CONTROL_MANDATORY is checked whenever any atomic right except CONTROL_MANDATORY and OWNER, is GRANTED or DENIED in modes, even if no actual change of the current access control list is necessary (it should be checked only when a change is made). If all rights are set to UNDEFINED in modes, CONTROL_MANDATORY is checked only if necessary. !discussion DI-4393/1 !sender Barry Bird/EDS !date 1994-05-24 [1] OBJECT_OWNER_VALUE_WOULD_BE_INCONSISTENT_WITH_ATOMIC_ACL cannot apply here as it relates to default object owner which is not relevant. The issue is that an ATOMIC ACL change is being made, which can be inconsistent with the OWNER rights on the object as well as with an outer object. If we look at 19.1.2(25) we see the relationship between OWNER rights and ATOMIC rights of components (only the CONTROL_DISCRETIONARY mode is significant). The atomic object of the composite object is also included. So the object must be considered as well as the outer object. The appropriate error is OBJECT_OWNER_CONSTRAINT_WOULD_BE_VIOLATED, temporarily removed from PCTE but restored by EP-4098. However, the text does need to be amended to include the object. This error also applies if scope is COMPOSITE. Add to 19.2.4: OBJECT_OWNER_CONSTRAINT_WOULD_BE_VIOLATED(/object/) Add to C.4 OBJECT_OWNER_CONSTRAINT_WOULD_BE_VIOLATED(/object/) An attempt to change the atomic or composite access control list of /object/ would result in an inconsistency with the OWNER rights on the object or an outer object. This replaces the existing resolution of EP-4098. [2] Add to 19.2.4: CONTROL_WOULD_NOT_BE_GRANTED(/object/) (EP-1095) [3] This only makes sense if the first and third 'CONTROL_MANDATORY' is replaced with 'CONTROL_DISCRETIONARY'. This I think is a comment on an earlier draft of this operation, and the point is now covered. !recommend [1] Add to Part 1/19.2.4: OBJECT_OWNER_CONSTRAINT_WOULD_BE_VIOLATED(/object/) Add to Part 1/C.4: OBJECT_OWNER_CONSTRAINT_WOULD_BE_VIOLATED(/object/) An attempt to change the atomic or composite access control list of /object/ would result in an inconsistency with the OWNER rights on the object or an outer object. [2] Add to Part 1/19.2.4: CONTROL_WOULD_NOT_BE_GRANTED(/object/) [3] !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4394 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (9.3.1) !date 1994-02-24 !clause Part 1/19.3.4 !priority medium !title program_group_add_member The key of the link "program_member_of" is the group identifier (key of the "known_security_group" link from the security directory to group). !discussion DI-4394/1 !sender Barry Bird/EDS !date 1994-05-24 Implementation choice. No change. !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4395 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (9.3.2) !date 1994-02-24 !clause Part 1/19.3.5 !priority medium !title program_group_add_subgroup The key of the link "program_subgroup_of" is the group identifier (key of the "known_security_group" link from the security directory to group). !discussion DI-4395/1 !sender Barry Bird/EDS !date 1994-05-24 Implementation choice. No change. !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4396 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (9.3.3) !date 1994-02-24 !clause Part 1/19.3.8 !priority medium !title user_group_add_member The key of the link "user_member_of" is the group identifier (key of the "known_security_group" link from the security directory to group). !discussion DI-4396/1 !sender Barry Bird/EDS !date 1994-05-24 Implementation choice. No change. !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4397 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (9.3.4) !date 1994-02-24 !clause Part 1/19.3.9 !priority medium !title user_group_add_subgroup The key of the link "user_subgroup_of" is the group identifier (key of the "known_security_group" link from the security directory to group). !discussion DI-4397/1 !sender Barry Bird/EDS !date 1994-05-24 Implementation choice. No change. !recommend No change. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4398 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (10.1) !date 1994-02-24 !clause Part 1/20.1.8 !priority medium !title Built-in Policy Aspects The predefined SDSs (and the types and type_in_sdss included) do not have the WRITE_ATTRIBUTES, WRITE_LINKS, APPEND_LINKS and DELETE access DENIED to ALL_USERS since one may want to add information (other than schema information) on them. !discussion DI-4398/1 !sender Barry Bird/EDS !date 1994-05-24 I think it is very dangerous to allow these permissions, particularly DELETE. !discussion DI-4398/2 !sender Martin Kirby/EDS !date 1995-03-01 The statement that "contain one entry" suggests this is the only entry for any group since there is only ever one entry for a group. Does it mean "an entry" rather than "one entry"? It is expected for environments to associate objects with sds's and type in sds. To prevent this on the pre-defined sds seems overly restrictive. I would prefer that the SECURITY_POLICY_WOULD_BE_VIOLATED applied to any use of a section 10.2 method on a pre-defined Sds except as the from_sds to one of the import operations. !recommend No change; potential security breach. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4399 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (11.1.1) !date 1994-02-24 !clause Part 1/21.1.1 !priority medium !title Audit Files The field WORKSTATION is of type execution_site_identifier (respectively Natural) !discussion DI-4399/1 !sender Barry Bird/EDS !date 1994-05-24 In 21.1.1(4), change 'WORKSTATION : Exact_identifier' to 'WORKSTATION : Execution_site_identifier' !recommend Accept DI-4399/1. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4400 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (12.1.1) !date 1994-02-24 !clause Part 1/22.1.2 !priority medium !title 22.1.2 The fields CONSUMER_GROUP and RESOURCE_GROUP are of type Group_identifier instead of Exact_identifiers. !discussion DI-4400/1 !sender Barry Bird/EDS !date 1994-05-24 In 22.1.2(3): Replace CONSUMER_GROUP : [Exact_identifier] by CONSUMER_GROUP : [Consumer_identifier] Replace RESOURCE_GROUP : [Exact_identifier] by RESOURCE_GROUP : [Resource_identifier] !recommend Accept DI-4400/1. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4401 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (14) !date 1994-02-24 !clause Part 2/Appendix C !priority medium !title New errors added to ECMA-149 PCTE_ATTRIBUTE_VALUE_LIMIT_WOULD_BE_EXCEEDED(initial_value): the specified initial_value exceed the limits defined for the value type of the attribute type. PCTE_CONTENTS_FORMAT_IS_INVALID(file): the contents of file have not been created by the queue_save operation. PCTE_NO_PARENTS(parent_types): parent_types is an empty list of types. PCTE_NO_ENUMERALS(enumeral_values): enumeral_values is an empty list of types. PCTE_OBJECT_OWNER_CONSTRAINT_WOULD_BE_VIOLATED(object): One of the constraints associated with the OWNER access right would be violated on object. PCTE_PARENT_TYPES_ARE_MULTIPLE(parent_types): an object type occurs more than once in parent_types. PCTE_PROCESS_IS_TERMINATED(process): process has process status TERMINATED PCTE_OPTIONAL_FACILITY_IS_NOT_SUPPORTED: an attempt has been made to use one of the ECMA PCTE optional facilities which is not supported by the ECMA PCTE implementation. !discussion DI-4401/1 !sender Barry Bird/EDS !date 1994-05-24 Error ATTRIBUTE_VALUE_LIMIT_WOULD_BE_EXCEEDED occurs 5 times but has no definition in Appendix C. I propose that in 10.2.8(11), 10.2.9(11), 10.2.10(11), 10.2.13(11) and 10.2.14(11) replace 'ATTRIBUTE_VALUE_LIMIT_WOULD_BE_EXCEEDED' by 'VALUE_LIMIT_ERRORS'. Add to 14.2.11: CONTENTS_FORMAT_IS_INVALID(/file/) and C.4: CONTENTS_FORMAT_IS_INVALID(/file/) 'The contents of file /file/ were not saved by the QUEUE_SAVE operation.' NO_PARENTS: see EP-4025. Add to 10.2.11: OBJECT_TYPE_WOULD_HAVE_NO_PARENT_TYPE(/parents/) Add to C.4: OBJECT_TYPE_WOULD_HAVE_NO_PARENT_TYPE(/parents/) 'An object type would be created with an empty set /parent/ of parent object types.' NO_ENUMERALS. Similarly error should be Add to 10.2.7 ENUMERATION_ATTRIBUTE_WOULD_HAVE_NO_ENUMERAL_TYPES(/values/) Add to C.4: ENUMERATION_ATTRIBUTE_WOULD_HAVE_NO_ENUMERAL_TYPES(/values/) 'An enumeration attribute type would be created with an empty sequence /values/ of enumeral types.' OBJECT_OWNER_CONSTRAINT_WOULD_BE_VIOLATED: covered by EP-4098. PCTE_PARENT_TYPES_ARE_MULTIPLE: (10.2.11) this is a problem in the Abstract Spec. because a set cannot have an element more than once, but plainly the error can occur in the bindings, because sets are mapped to sequences. So the error should be added to both the C and Ada bindings. Part 2: Add comment to 10.2(19): 'If the same object type occurs more than once in |parents| then error PCTE_PARENT_TYPES_ARE_MULTIPLE is raised.' Add PCTE_PARENT_TYPES_ARE_MULTIPLE to 25.1(1) and to 25.1(2): 'PCTE_PARENT_TYPES_ARE_MULTIPLE may be raised by any operation with an input parameter which is a sequence of object types and two of those object types are the same.' Similarly for Part 3. PROCESS_IS_TERMINATED: in 13.5.6(3), replace 'PROCESS_IS_TERMINATED' by 'PROCESS_HAS_NOT_GOT_REQUIRED_STATUS'. OPTIONAL_FACILITY_IS_NOT_SUPPORTED: I seem to remember that we agreed that 'calls to operations which are part of optional modules which are not implemented by an implementation will return with no error and no effect'. It may be worth adding that to 8.7.3. !recommend (1) In Part 1/10.2.8(11) replace 'ATTRIBUTE_VALUE_LIMIT_WOULD_BE_EXCEEDED' by 'VALUE_LIMIT_ERRORS'. (2) In Part 1/10.2.9(11) replace 'ATTRIBUTE_VALUE_LIMIT_WOULD_BE_EXCEEDED' by 'VALUE_LIMIT_ERRORS'. (3) In Part 1/10.2.10(11) replace 'ATTRIBUTE_VALUE_LIMIT_WOULD_BE_EXCEEDED' by 'VALUE_LIMIT_ERRORS'. (4) In Part 1/10.2.13(11) replace 'ATTRIBUTE_VALUE_LIMIT_WOULD_BE_EXCEEDED' by 'VALUE_LIMIT_ERRORS'. (5) In Part 1/10.2.14(11) replace 'ATTRIBUTE_VALUE_LIMIT_WOULD_BE_EXCEEDED' by 'VALUE_LIMIT_ERRORS'. (6) Add to Part 1/14.2.11: CONTENTS_FORMAT_IS_INVALID(/file/) (7) Add to Part 1/C.4: CONTENTS_FORMAT_IS_INVALID(/file/) The contents of the file /file/ were not saved by QUEUE_SAVE. (8) Add to Part 1/10.2.11: OBJECT_TYPE_WOULD_HAVE_NO_PARENT_TYPE(/parents/) (9) Add to Part 1/C.4: OBJECT_TYPE_WOULD_HAVE_NO_PARENT_TYPE(/parents/) An object type would be created with an empty set /parent/ of parent object types. ENUMERATION_ATTRIBUTE_WOULD_HAVE_NO_ENUMERAL_TYPES (/values/) An enumeration attribute type would be created with an empty sequence /values/ of enumeral types. (10) Add to Part 1/10.2.7: ENUMERATION_ATTRIBUTE_WOULD_HAVE_NO_ENUMERAL_TYPES (/values/) (11) In Part 2/10.2(19) add comment: If the same object type occurs more than once in |parents| then the error PCTE_PARENT_TYPES_ARE_MULTIPLE is raised. (12) In Part 2/25.1(1) add error PCTE_PARENT_TYPES_ARE_MULTIPLE. (13) In Part 2/25.1(2) add: PCTE_PARENT_TYPES_ARE_MULTIPLE may be raised by any operation with an input parameter which is a sequence of object types and two of those object types are the same. (14) In Part 3/10.2(11) add comment If the same object type occurs more than once in |parents| then the error PCTE_PARENT_TYPES_ARE_MULTIPLE is raised. (15) In Part 3/25(25) add error PCTE_ERROR_TYPES_ARE_MULTIPLE. (16) In Part 3/25 add after 25(28): PCTE_PARENT_TYPES_ARE_MULTIPLE may be raised by any operation with an input parameter which is a sequence of object types and two of those object types are the same. (17) In Part 1/13.5.6(3) replace 'PROCESS_IS_TERMINATED' by 'PROCESS_HAS_NOT_GOT_REQUIRED_STATUS'. (18) Add to Part 1/8.7.3 '- calls to operations which are part of optional modules which are not implemented by an implementation return with no error and no effect'. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4402 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (14) !date 1994-02-24 !clause Part 2/Appendix C !priority medium !title New errors added to ECMA-158 PCTE_STRING_TOO_SHORT(string): string is passed as or as part of an output parameter and there is not enough space in string.array. !discussion DI-4402/1 !sender Barry Bird/EDS !date 1994-05-24 Covered by EP-4066. !recommend Covered by EP-4066 (implemented in ISO/IEC 13719). !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4403 !status unresolved !sender Gerard Boudier,Emeraude !reference Comments_on_ECMA-149_and_ECMA-158_from_Emeraude (14) !date 1994-02-24 !clause Part 1/Appendix D.1 !priority medium !title System SDS changes [1] The predefined attribute last_composite_modification_time (exceeding MAX_NAME_SIZE characters) has been renamed last_composite_modif_time. [2] The predefined attribute message_coun has been renamed message_count. The link types lock and locked_by have been defined as two unidirectional designation links. (instead of a designation-designation relationship type which is no longer allowed) [3] The link types mounted_on and mounted_volumes have been defined as two unidirectional designation links. [4] The link types administration_volume_of and associated_administration_volume have been defined as two unidirectional designation links. [5] The link types is_listener and listened_to have been defined as two unidirectional designation links. [6] The usage_mode for the link type initial_process is not protected. [7] The key of the link types lock and locked_by are string attribute types (a natural is not enough to characterize a lock in a multi- servers environment) !discussion DI-4403/1 !sender Barry Bird/EDS !date 1994-05-24 [1] In 9.1.1(8), replace "last_composite_modification_time" by "last_composite_modif_time" [2] "message_coun": covered by EP-4233[7]. [3] "lock" and "locked_by" are no longer reverses: covered by EP-4103. [4] "mounted" and "mounted_on" are no longer reverses: covered by EP-4102. [5] "administration_volume_of" and "associated_administration_volume" are no longer reverses: covered by EP-4102. [6] "is_listener" and "listened_to" are no longer reverses: covered by EP- 4102. [7] Replace in 18.1.2(8) 'initial_process : (navigate)' by 'initial_process :'. [8] Insert after 9.1.1(3): 'lock_identifier: (read) string;' In 9.1.1(8), replace '(number) to activity' by '(lock_identifier) to activity'. In 16.1.2(7), replace '(number) to object' by '(lock_identifier) to object'. Add to end of 16.2.6(10): 'The keys of the "lock" and "locked_by" links are implementation- dependent. !discussion DI-4403/2 !sender John Dawes/ICL !date 1994-06-24 Shouldn't the addition to 16.2.6(1) be in 16.1.2 as well or instead? It seems to say something about the values of lock identifiers in general. !recommend (1) In Part 1/9.1.1: - in 9.1.1(8) replace "last_composite_modification_time" by "last_composite_modif_time"; - in 9.1.1(43) replace the first 'modification' by 'modif (modification)'. (2) In Part 1/D.1: - in D.1(9) replace "last_composite_modification_time" by "last_composite_modif_time"; - in D.1(3) insert 'lock_identifier : (read) string;'; - in D.1(36) replace '(number) to object' by '(lock_identifier) to object'. (3) In Part 1/18.1.2(8) replace 'initial_process : (navigate)' by 'initial_process :'. (4) Insert after Part 1/9.1.1(3): 'lock_identifier: (read) string;'. (5) In Part 1/9.1.1(8) replace '(number) to activity' by '(lock_identifier) to activity'. (6) In Part 1/16.1.2(7), replace '(number) to object' by '(lock_identifier) to object'. (7) Add to end of Part 1/16.2.6(10): The keys of the "lock" and "locked_by" links are implementation- dependent. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4404 !status unresolved !sender Dirk Daebertitz !reference Comment during TGOO7 !date 1994-02-24 !clause Part 1/9.1.1 !priority medium !title Num of incoming links The type of this attribute should be natural !recommend In Part 1/9.1.1(8) replace: num_incoming_links: (|read|) |non_duplicated integer| by: num_incoming_links: (|read|) |non_duplicated natural|; !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4409 !status unresolved !sender TGOO !reference Udo Kelter !date 1994-05-05 !clause Part 1/9.3.20 !priority medium !title Navigate access to volume object !comment Does someone have any idea what the expression ``which allows NAVIGATE access from the calling process'' in AS 9.3.20(3) could mean? Does this refer to the navigate right from the volume object? (Would be a nonsense) (1) VOLUME_LIST_OBJECTS( volume : Volume_designator, types : Object_type_nominators ) objects : Object_designators (2) VOLUME_LIST_OBJECTS returns in objects a set of object designators determined by types. (3) An object designator is returned in objects for each object which resides on volume, whose type in working schema is an element of types, and which allows NAVIGATE access from the calling process. (4) A read lock of the default mode is obtained on volume. Errors (5) ACCESS_ERRORS(volume, ATOMIC, READ, READ_LINKS) (6) REFERENCE_CANNOT_BE_ALLOCATED !discussion DI-4409/1 !sender Barry Bird/EDS !date 1994-05-05 Yes, this is a little strange. The words have not changed since edition 1. My interpretation is that only objects for which the calling process has NAVIGATE permission are included in the returned set of objects. READ_LINKS permission is required on the volume object. The rationale for this restriction escapes me. I gave my interpretation of what implementors are currently required to do, which I think is correct. I make no attempt to justify it. If it is possible to add an amendment to the ISO resolution document to remove this requirement from the Spec. it would have my support. Since I believe READ_LINKS in effect implies NAVIGATE there is no security requirement for NAVIGATE permission on the volume object, and it seems always possible to obtain an object reference of an object to which the caller has no access permission, mandatory or discretionary, whatsoever. By the way, in 23.1.2.2(20) as a minimum 'READ, NAVIGATE' should be changed to 'SYSTEM_ACCESS' since a link is incoming to this object, no outgoing links are involved, so no discretionary access permission should be checked. The entire error could be removed since the checks it covers including mandatory access permissions will be made when the object reference is used in any operation. Do you agree to this further change, removing 23.1.2.2(20)? !discussion DI-4409/2 !sender Barry Bird/EDS !date 1994-05-05 Regarding the possibility of amending to the ISO resolution document the point here is that NAVIGATE permission on the volume object would not make sense to distinguish destination objects: it applies to all outgoing links of the volume object, the presence or absence of this right cannot be used to distinguish some of the outgoing links and their destination objects (this seems to be assumed in the phrase ``.... each object which ...., and which allows NAVIGATE access from the calling process'' in 9.3.20(3)). In all, I think we agree that the phrase ``and which allows NAVIGATE access from the calling process'' should be deleted. I agree to the change to 'SYSTEM_ACCESS' You are probably right about removing the checks , but it is difficult to verify that any operation has already an appropriate ACCESS_ERROR. It is not clear to me whether we would need additional errors for OBJECT_REFERENCE_.. operations if we drop this. This would have to be checked. !discussion DI-4409/3 !sender Barry Bird/EDS !date 1994-05-05 I agree that there should be two small changes to ECMA-149 (DIS 13719-1): 9.3.20(3): remove last part of sentence after comma. 23.1.2.2(20): change READ,NAVIGATE to SYSTEM_ACCESS. !discussion DI-4409/4 !sender John Dawes/ICL !date 1994-06-24 I take it the second comma is meant; and that the comma should also be deleted! !recommend (1) In Part 1/9.3.20(3) remove last part of sentence after comma, and replace the comma by a full stop. (2) In Part 1/23.1.2.2 change READ, NAVIGATE to SYSTEM_ACCESS. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4410 !status unresolved !sender TGOO !reference Barry Bird/EDS !date 1994-5-10 !clause Part 3/10 !priority medium !title Clause 10 operations in ECMA-149 usually have type nominators in sds as parameters. These are always strings. See 23.1.2.6 - local names or type identifiers. I am surprised to see type references (limited private p.19) to the operations in the Ada binding. This looks like a MAJOR ERROR! I haven't time to deal with this now in detail - but look at the C binding. To me it looks at this moment as if many operations in clause 10 of the Ada binding will need to be changed!! - and some new types defined. I hope you can persuade me I am wrong, but why for instance does the C operation Pcte_sds_add_destination have parameters for link_type and object_type which are strings, but the Ada operation has type references which must be handled by operations in 23.4? I think that this is a major blunder in ECMA-162 that no-one has noticed in 11 months! !discussion DI-4410/1 !sender Richard Stuckey/ICL !date 1994-05-05 Barry, I think that this Clause 10 problem may be partly a historical error. If you look at Edition 1 of ECMA-162, you will see that all of the operations, whether OMS operations or clause 10 operations, had parameters of the type 'Pcte.type_reference' where types were required, and this type was a string type. Also, all the link operations had parameters of the type 'Pcte.link_reference', which was also a string type. However, in Edition 2 of the standards, the concept of handles (or internal references) for types and links, as well as for objects, was introduced; so these two types became private types - so all the Clause 10 parameters became the private type, as well as the OMS parameters! It would be possible to re-introduce a string type for the Clause 10 parameters;however, this would cause a problem in that the Ada operations such as PCTE_SDS.CREATE_OBJECT_TYPE return the new type as an out parameter - so if this were a string type, there would be the problem of the caller having to pass a sufficiently long string variable as the actual parameter, and the procedure would have to have another out parameter (of type PCTE.NATURAL) to give the caller the length of the actual string returned in this variable. (In fact, I remember that this point came up a long time ago: do you remember that long session that you and I had at Winnersh on resolving problems in the ECMA-162 Edition 1? I pointed out that these actual length out parameters were needed, and you said that these types were going to change anyway in Edition 2, to be type references (as they are now)). It would be possible for these procedures to be turned into functions, which return the string as their result, so avoiding the length parameter; however, this would not be possible for the CREATE_RELATIONSHIP_TYPE operation, which must return TWO such types - so this operation would have to be mapped differently from the other type creation operations. There would also be a similar problem with the PCTE_SDS.GET_LINK_TYPE_PROPERTIES operations, which have two out parameters, one of which is a type. In defence of the present operation signatures, I will say that I have just upgraded our DDL compiler and decompiler to use the ECMA PCTE Ada interfaces (rather than the PCTE+ ones), and encountered no problems as regards usability of the operations. As a matter of fact, it seems a little odd to me that the ECMA-149 standard should define a concept of handles for types, and use these handles in some operation (e.g. OMS operations) signatures, but then reverts to using type names in the Clause 10 operations for manipulating types! If the use of type names is sufficient, why have handles? Alternatively, if type handles are more efficient than type names, why not use them everywhere? There does seem to be an inconsistency here. !discussion DI-4410/2 !sender Barry Bird/EDS !date 1994-05-05 Yes, I can see the reasons why the error occurred. It is nonetheless an error. I should have picked it up last year. You raise some little difficulties with out string parameters, but they should be soluble. The strings are of limited length, MAX_NAME_SIZE, I think. There is no inconsistency. OMS operations deal with types in working schema and are thought to require the efficiency gains of type handles. SMS operations deal with types in SDS (on the whole) and do not require to be tremendously efficient. !discussion DI-4410/3 !sender Richard Stuckey/ICL !date 1994-05-05 However, I have now looked at this problem in a little more detail, and I don't see any real need for the type creation operations to have out parameters at all! In ECMA-149, these out parameters are of type 'type_nominator_in_sds', which according to 23.1.2(2) are mapped to 'type names in SDS'. From 23.1.2.6, we see that a type name in SDS is either a local name or a type identifier, but that a type in SDS returned by an operation is ALWAYS a local name - so this means that the out parameter from a type creation operation is actually the local name of the type that was specified as an in parameter to the operation! This is not incorrect, but it does seem pointless. There is a minor inconsistency here in that the local name in parameter is optional, and if it is not supplied than the created type is anonymous, and can only be referred to by its type identifier - so what is returned in this case? A null name - i.e. an empty string in the language bindings? The only real use for these out parameters would be if they returned the type identifiers of such anonymous types, but they do not; so if such a type is created, how can it then be used for anything? For example, if I create an anonymous attribute type, how do I find its type identifier so that I can then apply it to an object or link type? It is worth remembering that these operations are almost certainly going to be used only by a DDL compiler, or some other SDS creation tool - it is hard to think of an application that would need to modify dynamically the SDSs that it uses. So if an anonymous type really is required (e.g. as an implicit reverse link type), there is nothing to prevent the compiler creating such a type with a local name, using that name in whatever subsequent application operation s are` required, then removing the name with the SDS_SET_TYPE_NAME operation. So I see no real loss of functionality/useability in removing the out parameters and making the local name in parameters non-optional on these operations, and it would have very little impact on tools or applications. !discussion DI-4410/4 !sender Barry Bird/EDS !date 1994-05-27 Changes to DIS 13719 part 3: (1) Add to 8.4 (Package Pcte): subtype type_name_in_sds is Pcte.text(1..MAX_NAME_SIZE); (2) Add after 8.4(201): package type_names_in_sds is ... here take a standard sequence package specification e.g. object_references and replace "object_reference" by "type_name_in_sds" and "object_references" by "type_names_in_sds". end type_names_in_sds; (3) In 10.1(9, 13 (twice)), replace 'type_references.sequence' by 'type_names_in_sds.sequence'. (4) In 10.1(11), add after 'value': ' enumeral_types : Pcte.type_names_in_sds.sequence'. [This covers the original point which made me realise this error.] (5) In 10.2(1) replace 'Pcte.type_reference' by 'Pcte.type_name_in_sds', twice. In 10.2(2) replace 'Pcte.type_reference' by 'Pcte.type_name_in_sds', twice. In 10.2(3) replace 'Pcte.type_reference' by 'Pcte.type_name_in_sds', twice. (6) In 10.2(4-11, 13, 14) replace 'Pcte.type_reference' by 'Pcte.type_name_in_sds' and add new parameter 'new_type_length : out Pcte.natural;'. (7) In 10.2(5, 7, 11), replace 'type_references.sequence' by 'type_names_in_sds.sequence'. (8) In 10.2(12) replace 'Pcte.type_reference' by 'Pcte.type_name_in_sds' twice and add two new parameters 'new_forward_type_length : out Pcte.natural; new_reverse_type_length : out Pcte.natural;'. (9) In 10.2(16-19) replace 'Pcte.type_reference' by 'Pcte.type_name_in_sds'. (10) In 10.2(22) replace 'Pcte.type_reference' by 'Pcte.type_name_in_sds', twice. (11) In 10.2(23, 24, 26, 27, 28, 29) replace 'Pcte.type_reference' by 'Pcte.type_name_in_sds'. (12) In 10.2(30) replace 'Pcte.type_reference' by 'Pcte.type_name_in_sds', twice. (13) In 10.2(31) replace 'Pcte.type_reference' by 'Pcte.type_name_in_sds', twice. (14) Add to beginning of 10.3(1) the comment: -- If the abstract operation returns an enumeration value type in /value_type/ -- then properties.type_is is set to ENUMERAL_TYPE and -- properties.enumeral_types contains the sequence of enumeral type nominators. (15) In 10.3(1, 2, 5, 6, 7, 8, 9, 10, 11, 12) replace 'Pcte.type_reference' by 'Pcte.type_name_in_sds'. (16) In 10.3(3, 4) replace 'Pcte.type_reference' by 'Pcte.type_name_in_sds', twice. (17) In 10.3(4) add new parameter 'reverse_type_length : out Pcte.natural;'. (18) In 10.3(9, 10, 11, 12, 13, 14), replace 'type_references.sequence' by 'type_names_in_sds.sequence'. In 10.4, type references are used correctly. On DI-4410/3 returned type nominators in sds from SDS type creation programs: Yes, this does look a little pointless. I suggest that if the type name is null then the type identifier is returned. This accords more with EP-4061. EP-4358 is related. This proposes full type names returned, which seems pointless since the sds prefix is an input parameter. In part 1, 23.1.2.6(3) replace second sentence by 'A type in SDS returned by an operation is a local name unless it is null in which case the type identifier is returned.'. !recommend (1-18) Accept DI-4410/4(1-18). (19) In 23.1.2.6(3) replace second sentence by 'A type in SDS returned by an operation is a local name unless it is null, in which case the type identifier is returned.'. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4411 !status unresolved !sender Hugh Davis/ICL !date 1994-05-09 !clause Part 1/7 !priority low !title Status of clause 7 !comment At TGOO-7, I was asked to consider whether some parts of clause 7 are normative; it is classified as informative in clause 1. My view is that it is almost entirely normative since it defines how the document works as a specification - this is not obvious as it is written partly in a specification language VDM-SL, partly in English and partly in notations such as DDL defined within the document. It can all be made normative by the following changes: Change title to Outline of the Specification or Explanation of the Specification. Delete (1), which describes clauses 6 and 7. Add to the end of (3): The DDL definitions of types is collected in the informative Annex (Appendix) D. Delete (11-15) - Appendixes A to D are referred to in earlier paragraphs; Appendix E is referred to for the appropriate place (21.1.2); Appendix F is to become an Index (see General Editing Instructions); Commentary is to become Notes according to IEC/ISO Directives Part 3. !discussion EP-4411/1 !sender John Dawes ICL !date 1994-05-21 I am undecided about making the present clause 7, Outline of the Standard, normative, but tend to think not. I agree that it includes a few normative statements (e.g. in (7)), but these are (or should be) given elsewhere more fully (in the case of 7(7) in 8.7) and are in clause 7 just for information. It seems to me that clause 7 should really be the Introduction (see Dir3/2.2.4: 'specific information or commentary about the technical content of the standard ...'), but that would disturb the clause numbering. So I propose: check that all normative statements in clause 7 are indeed made elsewhere, and leave clause 7 as informative. !discussion DI-4411/2 !sender Hugh Davis ICL !date 1994-05-21 I've discussed John's DI with him. I agree that clause 7 should retain its present informative function and therefore withdraw the proposals for change in my EP. I had overlooked that 5.2 already has the job of defining how the specification works. I therefore propose that 5.2 should be compared with clause 7(2-8) to improve 5.2 (possibly with a change of title) and to remove the impression that it is only saying things like the funny mathematical notation is VDM-SLS. !recommend Compare 5.2 with 7(2-9) to improve 5.2, if possible. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4412 !status unresolved !sender TGOO !reference Hugh Davis/ICL !date 1994-05-09 !clause Part 2/7 !priority low !title Status of clause 7 !comment At TGOO-7, I was asked to consider whether some parts of ECMA-149 clause 7 are normative and to check ECMA-158 and ECMA-162 as well. The bindings, unlike ECMA-149, do not list normative clauses and hence imply that all clauses are normative. I suggest they remain normative (thus conforming to IEC/ISO Directives Part 3). Clause 6 is a short outline of the contents of the standard and it doesn't matter whether it is classified as normative or informative. Clause 7 contains some material which is normative since it specifies conformance (7.1) or aspects of the relationship between the language independent specification and the language binding. 7.2 General Principles can be changed to a normative style by changing 'should' to 'is'. Note that the clause 7s have not been kept fully up to date and therefore contain some inaccuracies - this would be unacceptable even if they were classified as informative. !discussion EP-4412/1 !sender John Dawes ICL !date 1994-05-21 There are NO normative statements in clauses 6 and 7 of the Bindings; in particular 7.1 is informative (it is no more normative than stating that the text is in English); the C Binding version is badly worded however and should follow the style of the Ada Binding version. !discussion EP-4412/2 !sender Hugh Davis ICL !date 1994-05-21 See my DI on EP-4337. !recommend Covered by EP-4337 (implemented in ISO/IEC 13719). !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4413 !status unresolved !sender TGOO !reference Hugh Davis/ICL !date 1994-05-09 !clause Part 3/7 !priority low !title Status of clause 7 !comment N.B. The following is identical to a comment for ECMA-158: At TGOO-7, I was asked to consider whether some parts of ECMA-149 clause 7 are normative and to check ECMA-158 and ECMA-162 as well. The bindings, unlike ECMA-149, do not list normative clauses and hence imply that all clauses are normative. I suggest they remain normative (thus conforming to IEC/ISO Directives Part 3). Clause 6 is a short outline of the contents of the standard and it doesn't matter whether it is classified as normative or informative. Clause 7 contains some material which is normative since it specifies conformance (7.1) or aspects of the relationship between the language independent specification and the language binding. 7.2 General Principles can be changed to a normative style by changing 'should' to 'is'. Note that the clause 7s have not been kept fully up to date and therefore contain some inaccuracies - this would be unacceptable even if they were classified as informative. !discussion EP-4413/1 !sender John Dawes ICL !date 1994-05-21 There are NO normative statements in clauses 6 and 7 of the Bindings; in particular 7.1 is informative (it is no more normative than stating that the text is in English); the C Binding version is badly worded however and should follow the style of the Ada Binding version. !discussion EP-4413/2 !sender Hugh Davis ICL !date 1994-05-21 See my DI on EP-4337. !recommend Covered by EP-4337 (implemented in ISO/IEC 13719). !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4416 !status unresolved !sender TGOO !reference Barry Bird/EDS !date 1994-06-14 !clause Part 1/16.1.10 !priority high !title Locks Table Inconsistence !comment In 16.1.10 Table 9 the entry for link deletion in UNPROTECTED activities should be: WUN not RUN. This would then make the table consistent with 16.1.5(7). This was changed by EP-0624[2], but must be wrong. A read lock is entirely inappropriate for a deletion. DUN (what it said in edition 1) is also wrong because delete locks are not defined for links. Only a 1 character change is required. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4417 !status unresolved !sender TGOO !reference Barry Bird/EDS !date 1994-06-29 !clause Part 1/23.1.2.5 C.4 !priority high !title Invalid Type Handles Are type handles valid if the working schema is changed? There is nothing that says they are not, but there are distinct problems if type handles (evaluated type references) can be used after the type is no longer present in the working schema: - how is its usage mode determined? - how is type application determined (e.g. valid object types for a link type) - for attribute types, how is the initial value found for unset attributes when *_get_attribute is used? I suggest adding a statement at the end of 23.1.2.5: 'Any use of an evaluated type reference /reference/ as a parameter of an operation may additionally raise the following error: TYPE_REFERENCE_IS_INVALID(/reference/)' Add to C.4: TYPE_REFERENCE_IS_INVALID(/reference/) 'The type in working schema referenced by the evaluated type reference /reference/ no longer exists as a result of a call to PROCESS_SET_WORKING_SCHEMA.' This solution is intended to mean that if the type is still to be found in the new working schema its handle is still valid. !discussion EP-4417/1 !sender JeanCalude Groselin/Emeraude !date 1994-06-30 Concerning the EP from Barry, I strongly support its proposal except for the following statement: > I suggest adding a statement at the end of 23.1.2.5: > > 'Any use of an evaluated type reference /reference/ as a parameter of an > operation may additionally raise the following error: > TYPE_REFERENCE_IS_INVALID(/reference/)' The error should not occur if the type reference is a type identifier and the PCTE_CONFIGURATION is effective for the calling process, allowing to identify types which are not part of the working schema. So, replace 'Any' by 'The' and in the error code add at the end of the sentence 'and the PCTE_CONFIGURATION' program group is not effective for the calling process'. !discussion DI-4417/2 !sender Martin Kirby/EDS !date 1995-03-01 The TYPE_REFERENCE_IS_INVALID error for an internal reference should be removed. Normal use of type references is for a supporting module to statically declare type references which reference the types it uses. Once these have been evaluated they should remain referencing the type regardless of changes in working schema. The type reference identifies a type, not a type in working schema, so the visible associations etc. are determined at the time the operation is carried out. An implementation might decide to cache checks made against a type reference it is then its (trivial) job to invalidate them when the working schema changes - but that should be internal implementation detail. !discussion DI-4417/3 !sender Udo Kelter/University of Siegen !date 1995-03-11 Basically, I agree. In our tools, we are changing the working schema very often and it would be very inconvenient to re-create all type references. However, what happens after TYPE_REFERENCE_UNSET? (The 93 specs do not have an error for this case). !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4418 !status unresolved !sender TGOO !reference Barry Bird/EDS !date 1994-06-29 !clause Part 1/23.1.2.5(7) C.4 !priority high !title Type Handles for an SDS not in WS The sds name in a full type name: can the sds validly be an sds which is not in the working schema? There is nothing to forbid it. If an sds NOT in the working schema can be specified (of course the type must actually be IN the working schema to be valid), then certain side-effects must be catered for: - error if SDS is unknown - ACCESS_ERRORS for the SDS - read locking the SDS (which could cause a wait) In PCTE+/Ada (p.179), there was a restriction that the SDS had to be in the working schema. I suggest that we follow this by appending to the first sentence of 23.1.2.5(7) : 'which is a member of the sequence of SDS names in the current working schema' Add error (after para (15)): 'SDS_IS_NOT_IN_WORKING_SCHEMA(sds name part of full type name)' Add this error to C.4. !discussion DI-4418/1 !sender Martin Kirby/EDS !date 1995-03-01 I'm not convinced by this. On the one hand it does mean that evaluation is simpler but it does make it harder to write modules that use specific types since a module cannot assume a local name, so needs a full name, and probably should not assume the user's working schema. For example, I could define an object name attribute on objects as "PORTOS_OMS-object_name". Other users might prefer to import this into an sds of their own as "generic_object_name" and apply it to a type "generic_object" rather than the global type "object". Then a module I provided that displayed this attribute could reasonably set up a type reference to "PORTOS_OMS- object_name" but not require that the PORTOS_OMS is in the working schema, only that the application was visible on the types for which it was to be supported. On the other hand, component developers probably shouldn't assume they know the name of an Sds (as versioning, name conflicts, etc. mean these should be seen as an installation issue). So what I really want is to be able to create an internal type reference given an Sds object and a local name and for this to be independent of working schema. Given a method to do that then it would be acceptable for the normal name based method to require the Sds to be in the working schema. An operation like: TYPE_REFERENCE_IN_SDS_SET ( sds : Sds_designator, type : Type_nominator_in_sds ) new_reference : Type_reference Creates a new, internal, type reference to a type identified in a designated sds. Errors ACCESS_ERRORS (sds, ATOMIC, READ, READ_LINKS) SDS_IS_UNKNOWN (sds) TYPE_IS_UNKNOWN_IN_SDS (sds, type) !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4419 !status unresolved !sender TGOO !reference Barry Bird/EDS !date 1994-06-29 !clause Part 1/23.1.2.5(9) !priority high !title Invalid Type Handles LINK_GET_ATTRIBUTE using an attribute type identifier for an invisible type with PCTE_CONFIGURATION cannot be implemented in general because the initial value may not be accessible. I suggest adding this, and similar operations, to those not allowed in 23.1.2.5(9): Insert 'getting, ' after 'creating objects and links, '. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4420 !status unresolved !sender TGOO !reference Barry Bird/EDS !date 1994-06-29 !clause Part 1/23.1.2.3(5,6) !priority high !title Invalid Type Handles OBJECT_DELETE_ATTRIBUTE, among others, cannot work for type identifiers of invisible types with PCTE_CONFIGURATION effective because 23.1.2.3(6) will fail the operation because no type application information can be found for the attribute type. This is very unfortunate because that is the raison d'etre of these operations. I suggest prefixing 23.1.2.3(5) and (6) with: 'If the operation does not delete the attribute:' !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4421 !status unresolved !sender TGOO !reference Barry Bird/EDS !date 1994-06-29 !clause Part 1/10.4 C.4(262) !priority high !title Invalid Type Handles Operations in 10.4 can return the error TYPE_IS_UNKNOWN_IN_WORKING_SCHEMA. However, they have type nominators as parameters. These map to type references which are evaluated by these operations in 10.4 (see 23.1.2.1(10)) and so give rise to the errors in 23.1.2.5 e.g. OBJECT_TYPE_IS_NOT_VISIBLE. Since the definition of a visible type is that it is in a working schema (8.1(4)) these errors are the same, so which is raised? The difficulty with raising errors like OBJECT_TYPE_IS_NOT_VISIBLE is that the type kind is not always known e.g. 10.4.6 par excellence. However, 23.1.2.5(11) deals with it, so I suggest: - Delete error TYPE_IS_UNKNOWN_IN_WORKING_SCHEMA throughout 10.4 (13 cases). - Delete C.4(262): (this error is only used in 10.4 - checked electronically) !discussion DI-4421/1 !sender Martin Kirby/EDS !date 1995-03-01 EP-5026, and EP-5027 Although the two errors have the same meaning deleting the error from 10.4 is not sufficient since the case where the type reference is internal does not evaluate the type reference and therefore does not report the TYPE_IS_NOT_VISIBLE error from 23.1.2.5. See also EP-5026, 5027. !discussion DI-4421/2 !sender Barry Bird/EDS !date 1995-03-24 Should be considered with EP-5027. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4422 !status unresolved !sender TGOO !reference Barry Bird/EDS !date 1994-06-29 !clause Part 1/23.3.8(7) !priority high !title Invalid Type Handles Returning to link references, Error KEY_VALUE_AND_EVALUATION_POINT_ARE_INCONSISTENT can no longer apply because key values are not any longer evaluated in this way. Evaluation of link references is now a two-stage process. The evaluation point only refers to the first stage. The key is only evaluated when there is an origin object i.e. in an operation other than in clause 23. This is a correction to DI-4007/3. So: Delete (7) from 23.3.8. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-4423 !status unresolved !sender TGOO !reference Barry Bird/EDS !date 1994-06-29 !clause Part 1/C.4(50) !priority high !title Invalid Type Handles Change the wording in C.4 of EVALUATION_STATUS_IS_INCONSISTENT_WITH_EVALUATION_POINT so that it refers to any kind of reference, not just object references. See 23.3.8(8) and 23.4.1(3). Replace in C.4(50): 'object' by 'object, link or type'. !history Raised too late for consideration at the Ballot Resolution Meeting. ------------------------------------------------------------------------ !identifier EP-5001 !status unresolved !sender R.E.Stuckey, ICL !date 1994-08-01 !clause Part 3/7.2(7) !title Poor example of package hierarchy !comment RE: ECMA-162 Second Edition 7.2(7) second sentence. This is not a good example of a package hierarchy; something like 'For example, 'ACCOUNTING_LOG_READ' is mapped to 'Pcte_accounting.log.read'.' would be better (note also missing '.'). ------------------------------------------------------------------------ !identifier EP-5002 !status unresolved !sender B.D.Bird, EDS !date 1994-08-15 !clause Part 1/23.1.2.5 !title Correction to EP-4061 !comment I am sorry but I got the precise wording drafted in Geneva wrong for EP-4061. My drafted amendments for EP-4061 were done in too much of a hurry (probably to the sound of pneumatic drills) and the last two paragraphs added to 23.1.2.5 were garbled to say the least. I read it fast at the meeting and no-one understood it, not even me. If they had, they would have realised that the second half of the first paragraph could never apply: >When a type name is returned it is the local name of the first associated >type in SDS in the sequence of SDS names in the working schema, or if >there is no such local name, the full type name i.e. prefixed with an SDS >name, of the first associated type in SDS in the sequence of SDS names in >the working schema. If there is no local name, then there cannot be a full type name either! This is a result of changing my understanding of the meaning of 'local name in working schema' and not changing all the text to conform. The second paragraph >If another type Y in working schema has a local name which is the same as >the type X in working schema to be represented by the returned type name >but that local name of Y is associated with an earlier SDS in the >sequence of SDS names then the full type name for X as above is returned.' was originally there to clarify what 'no local name in working schema' meant, but no longer applies. A type only has no local name in working schema if it has no local name in any SDS in the working schema - but then it can't have a full type name either! The complete revision below is shorter and I think easier to understand - but does not say anything different from what was intended - honest! I hope you agree and can make the changes. Revised first part of EP-4061: Insert after 23.1.2.5(8): 'If a type name or a link name rather than a type reference or a link reference is returned by an operation: The type name or the link type name of the link name is returned: - as a type name if the type is visible and named in the working schema; - as a type identifier otherwise. When a type name is returned it is the local name of the first named associated type in SDS in the sequence of SDS names in the working schema, providing that this local name does not occur earlier in the sequence of SDS names for another type. In that latter case, the full type name i.e. prefixed with an SDS name, of the first associated type in SDS in the sequence of SDS names in the working schema is returned.' The changes for 23.4.4(3), 9.3.12(21) and Part2/9.3(20) are not affected. ------------------------------------------------------------------------ !identifier EP-5003 !status unresolved !sender Howard Kaikow !date 1994-10-01 !clause Part 1/general !title Style !comment I received ECMA-149 today, it took 16 days to reach me from Geneva. I expect that ISO/IEC 13719 will be very different editorially, at least I sure hope so. Where did the 'style' of using, e.g., (56) to number paragraphs come from. Will ISO accept that? I've never seen that in any style manual. The text also leaves a lot to be desired. In any case, I was looking at Appendix B and saw the term 'SDS'. I then looked for 'SDS' in the index. There is no entry for 'SDS', but there is one for 'sds' that points to page 61. However, page 61 does not define 'SDS', tho it uses the term. 'SDS' is actually defined on page 6 as a 'schema definition set', however, 'schema definition set' is not in the index. !discussion DI-5003/1 !sender Chris Brockway, ECMA !date 1994-10-03 Regarding editorial style and formatting aspects of ECMA-149 and ISO/IEC 13719: i) The paragraph-numbering convention was used in ECMA-149 for reasons of facilitating a lengthy and comprehensive worldwide comment exercise, conducted over a 2-year period prior to the submission to JTC1 fast-track, and during which over 3000 comments were made. This paragraph-numbering convention has been preserved in the final DIS text submitted to the ITTF. ii) The JTC1/SC22 Chairman has advised that, for DISs that use the fast-track process, there is no formal requirement that the final DIS text be forwarded to the ITTF 100%-aligned with ISO style; alignment being compulsory of course for a new edition of the IS that may be produced in the future. Notwithstanding this supposed state of affairs, the ECMA TC33 project editors have in fact made changes in style/format in producing the final DIS text to align quite closely with ISO. We will see the ITTF reaction, and the published standard, in due course. Regarding the indexing difficulty for 'SDS' or 'sds', John Dawes (Project Editor for JTC1/SC22/WG22) or Regis Minot (Chairman JTC1/SC22/WG22) may like to respond to you? I hope the above is of help. !discussion DI-5003/2 !sender Howard Kaikow !date 1994-10-04 > future. Notwithstanding this supposed state of affairs, the ECMA TC33 > project editors have in fact made changes in style/format in producing > the final DIS text to align quite closely with ISO. Good. > Regarding the indexing difficulty for 'SDS' or 'sds', John Dawes > (Project Editor for JTC1/SC22/WG22) or Regis Minot (Chairman > JTC1/SC22/WG22) may like to respond to you? It is really difficult to produce a 'complete' and accurate index. Recently, I began working on a WordBasic macro to assist in the verification of an index, however, there are bugs in Word that make this non-transparent, but likely doable. !discussion DI-5003/3 !sender Barry Bird/EDS !date 1995-03-24 Add SDS and Schema Definition Set to index of technical terms. Possibly a Note informally describing the function of SDSs would be useful to readers new to PCTE. Although this is not normally done, SDSs are such an important feature of PCTE they deserve special treatment. ------------------------------------------------------------------------ !identifier EP-5004 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/23.1.2.4 !title Evaluation of Link references !comment The KEY_IS_BAD error (13) cannot always be determined at first stage evaluation. The link type may not be supplied in which case the required number and type of keys is unknown. So, for simplicity, move the KEY_IS_BAD error (13) to after para (18). ------------------------------------------------------------------------ !identifier EP-5005 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/23.3.5 !title LINK_REFERENCE_GET_NAME !comment para (3) fails to deal with the case where there is no local or full name for the type in the current working schema. It should say: 'The link type name of /link_name/ is as specified by TYPE_REFERENCE_GET_NAME (23.4.4) with no sds supplied.' para (4) should be 'The key of /link_name/ is the key of the link reference before any evaluation.' Reason: the evaluation is only done in the context of an origin object, which is unspecified. para (5): parameter link_name is missing. ------------------------------------------------------------------------ !identifier EP-5006 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/23.3.8 !title LINK_REFERENCE_SET !comment Error LINK_NAME_AND_EVALUATION_POINT_ARE_INCONSISTENT(link_name, point) has been omitted. The error needs to be added to Appendix C. The text is: 'Link name /link_name/ has one of the forms A.B., A.1. or A.1 which require a preferred link type which is unavailable to this operation, and evaluation point /point/ is NOW.' ------------------------------------------------------------------------ !identifier EP-5007 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/C.4(122) !title text is wrong !comment C.4(122) text is wrong. Only for QUEUE_HANDLER_DISABLE. This operation does not request to go into listening mode, quite the reverse.Replace 'to go into listening mode' by 'to disable the handler'. (as a minimum) ------------------------------------------------------------------------ !identifier EP-5008 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/C.3.3(10) !title should be removed !comment C.3.3(10) should be removed. This applies to the case where a composition link is being created between two objects. In this case, the OWNER rights of the composite object are propagated as if OBJECT_SET_ACL_ENTRY was being performed on the destination. This changes CONTROL_DISCRETIONARY rights to be consistent with the new OWNER rights (19.2.4(7)) so that the error ATOMIC_ACL_IS_INCOMPATIBLE_WITH_OWNER_CHANGE cannot apply. Possibly this should be made clear in 9.2.1(17). ------------------------------------------------------------------------ !identifier EP-5009 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/19.2.4(17), C.4(1) !title two 'control would not be granted' errors !comment In OBJECT_SET_ACL_ENTRY there are two 'control would not be granted' errors. Delete the first 19.2.4(17). Then C.4(1) can be removed. ------------------------------------------------------------------------ !identifier EP-5010 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/C.4(32) !title wording should also be changed !comment The wording of C.4(32) should also be changed: replace 'no longer granted to any group in the atomic ACL of /new_object/ or one of its components' by 'granted and/or denied to groups in the atomic ACL of /new_object/ or one of its components such that no process would be permitted to modify the mandatory labels or the atomic ACL of /new_object/ or one of its components' Reason: if permissions are DENIED to ALL_USERS this negates any change to security attributes no matter how many groups are GRANTED permission. The important point is that SOMEONE must be able to make these changes. !discussion DI-5010/1 !sender Martin Kirby/EDS !date 1995-03-01 The proposed text raises many questions. When it says "no process" does it mean no existing process or no process that could exist, in the latter case it is impossible to calculate since there maybe other checks that prevent a process that apparently would have access from being created. I prefer to keep things simple as: would no longer be granted to any group or would be denied to the predefined ALL_USERS user group ... ------------------------------------------------------------------------ !identifier EP-5011 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/9.3.12 !title designation links with deleted destinations !comment OBJECT_LIST_LINKS, when applied to designation links with deleted destination objects, treats them as external links. Reason: since the destination is not accessible, it cannot be determined whether it is a component or not. Since it no longer exists, it is better to treat it as not a component. ------------------------------------------------------------------------ !identifier EP-5012 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/C.4(257) !title TYPE_IDENTIFIER_SYNTAX_IS_WRONG is unclear !comment TYPE_IDENTIFIER_SYNTAX_IS_WRONG C.4(257) is unclear. What does 'wrong' mean? How does this differ from TYPE_IDENTIFIER_IS_INVALID (which is implementation-defined 23.1.2.5(14))? TYPE_IDENTIFIER_SYNTAX_IS_WRONG differs from TYPE_IDENTIFIER_IS_INVALID only in that it refers to a name rather than a reference and what C.4(256) should say is: TYPE_IDENTIFIER_IS_INVALID(/reference/) 'The type reference /reference/ is a name which begins with an underscore but is not a type identifier as defined by the implementation.' Similarly C.4(257) should say: TYPE_IDENTIFIER_SYNTAX_IS_WRONG(/name/) '/name/ begins with an underscore but is not a type identifier which conforms to the syntax defined by the implementation.' !discussion DI-5012/1 !sender Martin Kirby/EDS !date 1995-03-01 TYPE_IDENTIFIER_IS_INVALID should mean that the name has the implementation defined syntax of a type identifier but that the implementation knows that the type identifier does not refer to any type that exists or has ever existed (for example, the implementation may high-water mark type identifiers or may define that type identifiers include the installation name as part of their format) ------------------------------------------------------------------------ !identifier EP-5013 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/13.2.1(23) !title Access rights for preexisting groups !comment 13.2.1(23) 'has two additional groups added, if not already present, and these groups have all access rights granted' If the groups are present then do they have all access rights granted or do the otherwise calculated access rights apply? Proposed resolution: This is unchanged from edition 1 of ECMA-149. Going back to PCTE+/C we see that if the groups are present then they do have all access rights granted. ------------------------------------------------------------------------ !identifier EP-5014 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/13.2.1(22, 28) !title References to SDS 'security' !comment Para (22): Reference to SDS 'security' should be to SDS 'discretionary_security'. SDS 'mandatory_security' can be excluded because of paras (26) and (27). Para (28): Reference to SDS 'security' should be to SDS 'discretionary_security' and 'mandatory_security'. ------------------------------------------------------------------------ !identifier EP-5015 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/9.4.3(9) !title Error in ACCESS_ERRORS !comment 9.4.3(9) second line should be (EP-4273): ACCESS_ERRORS(predecessor of X, COMPOSITE, CHANGE, STABILIZE). ------------------------------------------------------------------------ !identifier EP-5016 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/9. !title error OBJECT_CANNOT_BE_STABILIZED !comment There is an error OBJECT_CANNOT_BE_STABILIZED which can be raised from LINK_CREATE or LINK_REPLACE. However, the most common stabilizing link is predecessor yet VERSION_REVISE and VERSION_SNAPSHOT do not report this error. ------------------------------------------------------------------------ !identifier EP-5017 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/16.1.7(2) !title access rights needed to establish or promote a lock !comment Clause 16.1.7(2) states that at least one access right is needed to establish or promote a lock. Clause 9.3.1, for example, read locks an object but does not require any discretionary access rights to it. These clauses are contradictory. ------------------------------------------------------------------------ !identifier EP-5018 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/16.1.5(15) !title sounds like rubbish !comment In 16.1.5(15) the first, rather long, sentence says 'to a mode which has no relative strength with the mode' which sounds like rubbish. I expect the the second mode is meant to be the current mode and the first mode the attempted promotion. ------------------------------------------------------------------------ !identifier EP-5019 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/13.2.18(3, 4, 9) !title Missing case in WAIT_FOR_CHILD !comment The description of WAIT_FOR_CHILD in 13.2.18(3, 4, 9) does not cover the case where - acknowledged_termination is false, - the child is TERMINATED, and - the deletion conditions are not satisfied. The operation should simply return. Rephrase (3) by moving 'and the deletion conditions are satisfied' to the end of the sentence. The same change should also be made to 13.2.17(3), first sentence. It is not clear reading these two operations on their own what these 'deletion conditions' are. A Note should be added to both 'wait' operations either to refer to PROCESS_TERMINATE for these deletion conditions or to state more clearly what they are i.e. something like the process has no child processes or all its child processes have a READY or TERMINATED status and for which deletion upon termination is true. ------------------------------------------------------------------------ !identifier EP-5020 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/12.2.10 !title Problems with Contents_set_properties !comment Contents_set_properties requires no access checks and no locks yet there is no requirement that the handle has been opened for write. Thus there are: mandatory security problems problems with replicas problems with read only volumes possible confusions with transactions Proposed resolution: Add CONTENTS_OPERATION_IS_NOT_VALID to errors in clause 12.2.10 to be reported if the contents are a file or device open READ_ONLY. Add a note that the change is made under the aegis of the lock acquired at the time the contents were opened. ------------------------------------------------------------------------ !identifier EP-5021 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/16 !title object_on_volume links are subject to rollback !comment Statement omitted from IS 13719 that was to be added to clause 16 (EP-4041) to the effect that object_on_volume links are subject to rollback with their destination object although not locked. ------------------------------------------------------------------------ !identifier EP-5022 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/23.4.3, 23.4.4, 23.4.6 !title error TYPE_IS_NOT_VISIBLE should be added !comment When an invisible type reference is evaluated (and PCTE_CONFIGURATION is not effective) then ATTRIBUTE_TYPE_IS_NOT_VISIBLE, ENUMERAL_TYPE_IS_NOT_VISIBLE, LINK_TYPE_IS_NOT_VISIBLE, or OBJECT_TYPE_IS_NOT_VISIBLE is returned. If the type reference is evaluated in a context where its type kind cannot be deduced, which error is raised? This applies when TYPE_REFERENCE_SET is called for an invisible type name 'unknown' with evaluation point NOW. The errors in 23.1.2.5(11-16) should apply, but none does. The error TYPE_IS_NOT_VISIBLE should be added to 23.4.3, 23.4.4 (when sds is not supplied) and for 23.4.6: If /point/ is NOW: TYPE_IS_NOT_VISIBLE(/name/) TYPE_IS_NOT_VISIBLE should be added to the index of error conditions. It is declared in Appendix C, but not currently used. ------------------------------------------------------------------------ !identifier EP-5023 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/23.1.2.5(11-17) !title More errors for type references !comment The evaluation errors for type references 23.1.2.5(11-17) should also include the errors: SDS_IS_UNKNOWN TYPE_IS_UNKNOWN_IN_SDS They can arise when a full type name (which includes an SDS name) is given. ------------------------------------------------------------------------ !identifier EP-5024 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/23.4.3 !title TYPE_REFERENCE_GET_IDENTIFIER must evaluate the type reference !comment TYPE_REFERENCE_GET_IDENTIFIER 23.4.3 must evaluate the type reference. In order to determine the type identifier: - if the type name is a local name, it must determine which SDS it belongs to by use of the local name resolution rules; - if it is a local or full name, it must access the SDS to find the type id. It is only unnecessary if the type reference is initially a type identifier, which is hardly a useful way to use this operation! This means that all errors which can arise during type reference evaluation e.g. TYPE_IS_UNKNOWN_IN_SDS are possible with this operation. Add a sentence to 23.4.3(2): 'If the evaluation status of the type reference /reference/ is EXTERNAL, it is evaluated.' Note that 23.1.2.1(10) may need to be modified. ------------------------------------------------------------------------ !identifier EP-5025 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/23.4.4 !title TYPE_REFERENCE_GET_NAME must evaluate the type reference !comment TYPE_REFERENCE_GET_NAME 23.4.4 also must evaluate the type reference, since it must be able to give rise to the errors TYPE_IDENTIFIER_IS_INVALID SDS_IS_UNKNOWN TYPE_IS_UNKNOWN_IN_SDS TYPE_IS_NOT_VISIBLE This also applies to LINK_REFERENCE_GET_NAME. ------------------------------------------------------------------------ !identifier EP-5026 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/C.4 !title Identical errors !comment OBJECT_TYPE_IS_NOT_VISIBLE is defined as the same as OBJECT_TYPE_IS_UNKNOWN. Only the latter is used as far as I can see in operations which have object type references (nominators). For consistency only the former should be used and all places where OBJECT_TYPE_IS_UNKNOWN occurs it should simply be deleted. !discussion DI-5026/1 !sender Martin Kirby/EDS !date 1995-03-01 See DI-4421/1. ------------------------------------------------------------------------ !identifier EP-5027 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 1/10.4 !title Conflict of errors !comment Operations in clause 10.4 have type references as parameters (yes, see table 11), which must be evaluated as in clause 23.1.2.5. There is then, for invisible types, a conflict between the error TYPE_IS_UNKNOWN_IN_WORKING_SCHEMA and those in 23.1.2.5(12). It seems to me that either: - the error TYPE_IS_UNKNOWN_IN_WORKING_SCHEMA should be deleted throughout (and that would include Appendix C), or - a Note be added to explain that TYPE_IS_UNKNOWN_IN_WORKING_SCHEMA takes precedence over the similar clause 23 errors. 25. When operations in clause 10.4 execute for invisible types with PCTE_CONFIGURATION effective, is the error OPERATION_IS_NOT_ALLOWED_ON_TYPE returned? Or TYPE_IS_UNKNOWN_IN_WORKING_SCHEMA? I prefer the latter. !discussion DI-5027/1 !sender Martin Kirby/EDS !date 1995-03-01 See DI-4421/1. ------------------------------------------------------------------------ !identifier EP-5028 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 2/8.6(1) !title Alignment !comment 8.6(1) last bullet needs to be brought into line with clause 7.7. ------------------------------------------------------------------------ !identifier EP-5029 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 2/8.2.11(4), 25.1(1, 2) !title The same error has three different names !comment The same error has three different names! PCTE_STRING_TOO_SHORT: used in clause 8.2.11(4) PCTE_STRING_TOO_SMALL: used in clause 25.1(1) - definition of Pcte_error_type PCTE_STRING_IS_TOO_SHORT: used in clause 25.1(2) - commentary on definition of Pcte_error_type Which one should it be? In my opinion it should be PCTE_STRING_TOO_SHORT. Clause 25.1 should be brought into line. Evidence: In ECMA-158 8.2.11(4) it was PCTE_STRING_TOO_SHORT and this was the original name given (and failed to be given in 25.1!). The comment pointing this out was inaccurate and used the name PCTE_STRING_TOO_SMALL. The agreed change in the ISO disposition of comments document used PCTE_STRING_TOO_SHORT for the C binding, but STRING_IS_TOO_SHORT for the Ada binding. ------------------------------------------------------------------------ !identifier EP-5030 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 2/8.2.10 !title table about sequences is still wrong !comment 8.2.10 pcte-sequence This table about sequences is still wrong. Pcte_sequence_put now does not exist. The description of Tail must be wrong. How do s1 and s2 get to s? I have not checked the rest, but are also liable to contain errors. !discussion DI-5030/1 !sender Barry Bird/EDS !date 1995-03-24 Part 2, 8.2.10 Table Tail: parameter s should be s1. Or should it be s2? A more accurate set of operations would be (an alternative is to use Pcte_sequence_get_elements): Pcte_natural n; Pcte_sequence_create (-,NULL,0,&s2) Pcte_sequence_get_length (s1, &n) Pcte_sequence_copy (s1,s2,0,1,n-1) Append, Copy and Put: parameter &s2 to Pcte_sequence_copy should be s2. Insert before sequence_copy: Pcte_sequence_create (-,NULL,0,&s2) Append: Change sequence_put to sequence_insert, n+1 should be n. Put: Change sequence_put to sequence_insert. ------------------------------------------------------------------------ !identifier EP-5031 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 2/8.3 !title Pcte_reference_* should be Pcte_object_reference_* !comment There is a reference to a function called Pcte_reference_unset (and others) against Pcte_object_reference. These should be Pcte_object_reference_*. ------------------------------------------------------------------------ !identifier EP-5032 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 2/8.2.5(2-4, 7) !title Move the C code !comment Move the C code in 8.2.5(2-4) and (7) to the end of 8.7.2 (EP-4278). ------------------------------------------------------------------------ !identifier EP-5033 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 2/8.7.2 !title Misleading insertion !comment The insertion of PCTE_NULL_STRING (EP-4018) into 8.7.2 is highly misleading as it cannot be used with parameters of type Pcte_string although the paragraphs on either side deal with Pcte_string! I suggest either (a) 8.7.2(16, 17) be moved to before (15) and PCTE_NULL_STRING renamed PCTE_NULL_TEXT to avoid confusion, although I am not sure what it is to be used for, since "" can be used just as well, or (b) 8.7.2(17) be replaced by: Pcte_string Pcte_null_string = {0, ""}; possibly prefixed by extern. This really can be used as a genuine null input parameter of type Pcte_string and is probably more useful. ------------------------------------------------------------------------ !identifier EP-5034 !status unresolved !sender Barry Bird !date 1994-11-09 !clause Part 3/9.3(47) !title Misleading insertion !comment 9.3(47) should state that the error STRING_IS_TOO_SHORT is returned when the key parameter is too short to hold the returned value. (EP-4239) ------------------------------------------------------------------------ !identifier EP-5035 !status unresolved !sender John Dawes !date 1994-11-26 !clause Part 1/general !title Minor editing errors !comment [1] 1(1,2). 'This Standard' -> 'This part of ISO/IEC 13719'. [2] 1(3,4). 'this Standard' -> 'this part of ISO/IEC 13719'. Also 2.1(1- 5), 2.2(8,9,12-15,17(twice),18(twice),20,21), 4.2(5),.6.5(1), 13.1.4(15). [3] 2.2(17). 'an Standard' -> 'an International Standard'. [4] 3(7). 'charactaer' -> 'character'. [5] 6(1). 'this Standard' -> 'this International Standard'. Also 8.2.1(19), 8.7.2(7), 8.7.3(3,4), 13.1.4(33,43,55,62,63), 18.2.1(6), 23.1.1(1) line 2. [6] 7(12,13). Interchange 'Appendix D' and 'Appendix E' and transpose paragraphs (12) and (13). [7] 8.3.2(2). Second underline in 'Value_type_identifier' is underlined. [8] 9.1.1(58). 'this standard' -> 'this International Standard'. [9] 9.2.9(31). Delete this note, as it is covered by the new last part of 9.2.9(3) ('ignoring any ... on /dest/'). [10] 9.4.3(9). 'predecessor of /version/' -> 'predecessor of X'. [11] 13.2.1(53). Move to correct alphabetic place. [12] 22.2.1(2), sentence 2. 'are' -> 'is'. [13] 22.2.1(4). 'locks' -> 'lock'. [14] 22.2.6(2). Delete 'the master of'; similarly 22.2.9(2). [15] 22.2.7(4). 'The existence link of type "known_consumer_group" ' -> 'The "known_consumer_group" link'. [16] 22.2.10(4), line 1. Delete 'existence'. [17] 23.1.1(1), line 6. Delete 'JTC1/SC22'. [18] 23.1.1(1). 'the draft standard on Language-Independent Datatypes under production by ISO/IEC JTC1/SC22 CD 11404.2' -> 'ISO/IEC DIS 11404'. [19] 23.1.2.7(14). 'to give' -> 'giving' (to avoid misreading 'in order to'). [20] A.1(1), line 2. 'ISO-IEC' -> 'ISO/IEC'. [21] C.4(47). Move to correct alphabetic place. ------------------------------------------------------------------------ !identifier EP-5036 !status unresolved !sender John Dawes !date 1994-11-26 !clause Part 1/C.4 !title Redundant error conditions !comment The following error conditions in C.4 are not used in the body of ISO/IEC 13719 and should be removed: - (79) KEY_IS_NOT_SYSTEM_KEY - (97) LINK_REFERENCE_IS_NOT_EVALUATED - (194) PROCESS_IS_INACCESSIBLE ------------------------------------------------------------------------ !identifier EP-5037 !status unresolved !sender John Dawes !date 1994-11-26 !clause Part 1/Index of Error Conditions !title Missing references !comment The components of grouped error conditions in C.3.1, .2, and .3 should be indexed here; in particular that would add references for the following, which are not referred to elsewhere: - ATOMIC_ACL_IS_INCOMPATIBLE_WITH_OWNER_CHANGE - LINK_EXCLUSIVENESS_WOULD_BE_VIOLATED - REPLICATED_COPY_UPDATE_IS_FORBIDDEN ------------------------------------------------------------------------ !identifier EP-5038 !status unresolved !sender John Dawes !date 1994-11-26 !clause Part 1/General !title Wrong paragraph numbers !comment The following paragraph numbers are wrong: - 13.1.5(11,12) should be (10,11). - 13.3.7(37-44) should be (35-42). - 20.1.7(7-14) should be (6-13). - 21.11, second paragraph (13) should be (17). - 21.11(17-43) should be (18-44). - 23.1.3.1(3-12) should be (2-11). ------------------------------------------------------------------------ !identifier EP-5039 !status unresolved !sender Richard Stuckey !date 1994-12-16 !clause Part 1/23.3.8 !title Link reference problem !comment The LINK_REFERENCE_SET operation can take a key and a link type reference, but it has the error state EVALUATION_STATUS_IS_INCONSISTENT_WITH_EVALUATION_POINT which applies if the status of the type reference is internal (i.e. it has been evaluated) but the evaluation point of the operation is not NOW. This means that it is not possible to set up a link reference which has a fixed= type, but a variable key, e.g. the following sequence of operations is illegal: TYPE_REFERENCE_SET ("sds-linktype", NOW, TYPE_REF) LINK_REFERENCE_SET ("++", TYPE_REF, EVERY_USE, LINK_REF) It is of course possible to achieve the required effect by making the evaluationpoint for the type reference EVERY_USE, instead of NOW, so that its status is external, but only at the cost of having to evaluate the type reference every time the link reference is used (which may not give the required result, if the link type is renamed in the meantime!). It is not possible to specify NOW for the evaluation point of the link reference if the key is (e.g.) "+" or "++", as this would then result in the error KEY_VALUE_AND_EVALUATION_POINT_ARE_INCONSISTENT I admit that this is not a major problem as regards functionality, but it is a little nasty from the usability point of view (lest you think this is an artificial case, we fell over it on porting the ToolPark tool Tool Object Interfaces from V12.5 to PORTOS!). !discussion DI-5039/1 !sender Martin Kirby/EDS !date 1995-03-01 With the ISO change to two-stage evaluation of link references the example would normally want the link reference evaluated NOW since the "++" would still be evaluated every time the link reference was used. The KEY_VALUE_AND_EVALUATION_POINT_ARE_INCONSISTENT error should be deleted from LINK_REFERENCE_SET since the error condition (that the key evaluation failed) is not appropriate since the operation no longer evaluates keys ever. ------------------------------------------------------------------------ !identifier EP-5040 !status unresolved !sender Martin Kirby/mwk@sdsph.sdsci.co.uk/EDS !date 1995-01-16 !clause Part 1/13.2.12, 13 !title Serious error in PCTE security !comment The effect of this error is to allow anyone to use ANY SDS in their working schema. This totally negates the schema visibility concept since then all processes can in principle "see" any type. 13.2.12(19) (PROCESS_SET_WORKING_SCHEMA) appears to require EXPLOIT_SCHEMA permission on the SDS, but the effect of the SYSTEM_ACCESS parameter (see C.3.1) is to ignore this permission. In any case if the working schema of a process in READY state is changed by another process e.g. the parent, there is NO access check at all! 13.2.13(20) (PROCESS_START) makes no check for EXPLOIT_SCHEMA permission on any SDS. It should do so, since for example its effective groups could be changed from those inherited by PROCESS_ADOPT_USER_GROUP, even if the inherited working schema is unchanged. I propose: i) Delete ", EXPLOIT_SCHEMA" from 13.2.12(19) ii) Add DISCRETIONARY_ACCESS_IS_NOT_GRANTED (SDS with name in /sds_sequence/, ATOMIC, EXPLOIT_SCHEMA) to 13.2.12 as a new paragraph (and therefore applies whatever the process). This is in accord with the PCTE+/C Spec. as changed in PCTE+/CHANGES/C, and ECMA-149 edition 1. iii) Add DISCRETIONARY_ACCESS_IS_NOT_GRANTED (/sds/, ATOMIC, EXPLOIT_SCHEMA) to 13.2.13(20) -------------------- !discussion DI-5040/1 !sender Udo Kelter !date 1994-05-24 >The effect of this error is to allow anyone to use ANY SDS in their >working schema. This totally negates the schema visibility concept >since then all processes can in principle "see" any type. > >13.2.12(19) (PROCESS_SET_WORKING_SCHEMA) appears to require >EXPLOIT_SCHEMA permission on the SDS, but the effect of the >SYSTEM_ACCESS parameter (see C.3.1) is to ignore this permission. Quite obviously, an error has been introduced here. Unfortunately, I do not have a paper copy of the final version of the specs here, so I can hardly say much. > >In any case if the working schema of a process in READY state is >changed by another process e.g. the parent, there is NO access check > >at all!13.2.13(20) (PROCESS_START) makes no check for EXPLOIT_SCHEMA >permission on any SDS. It should do so, since for example its >effective groups could be changed from those inherited by >PROCESS_ADOPT_USER_GROUP, even if the inherited working schema is >unchanged. Of course! Hard to believe that this error has not been detected yet. > >I propose: > >i) Delete ", EXPLOIT_SCHEMA" from 13.2.12 (19) I do not have this text. > >ii) Add DISCRETIONARY_ACCESS_IS_NOT_GRANTED (SDS with name in >/sds_sequence/, ATOMIC, EXPLOIT_SCHEMA) to 13.2.12 as a new paragraph >(and therefore applies whatever the process). This is in accord with >the PCTE+/C Spec. as changed in PCTE+/CHANGES/C, and ECMA-149 edition >1. After searching the file with the ECMA2 specs, I found that EXPLOIT_SCHEMA is also required in all IMPORT operations. If there is a general error in the new structure of the ACCESS_ERRORS macro, the problem should be resolved there generally, rather thn only in 13.2.12 >iii) Add DISCRETIONARY_ACCESS_IS_NOT_GRANTED (/sds/, ATOMIC, >EXPLOIT_SCHEMA) to 13.2.13(20) I fear that things are more complicated: (1) We have yet another tricky problem here: The EXPLOIT_SCHEMA rights should, in my view, be checked using the discretionary context of the process for which the working schema is going to be used. If a process sets its own working schema, its own discretionary context must be used. If a process sets the working schema of another process, checking of the EXPLOIT_SCHEMA rights should be done on the basis of the discretionary context of the other process. The bad surprise is that this cannot be expressed at all using the existing errors since they always impicitly refer to the state of the calling process!!! I have no really convincing solution: Solution A: is to say in the specification of PROCESS_START that immediately after the start of the new process, it calls process_set_working_schema ( nil, sequence of SDSs identified by the sds_in_working_schema links from the started process) and produces all relevant errors. Thus, the operation is performed in the correct context. Another advantage would be that the error SDS_IS_UNDER_MODIFICATION would be checked at a better point in time. (Frankly speaking, I do not clearly understand this error. Do the sds_in_working_schema links to an SDS prevent its modification?) Solution B: to define a side-effect of PROCESS_ADOPT_USER_GROUP and PROCESS_SET_USER_AND_USER_IDENTITY (and anything else which changes the discretionary context of a process) to unset the current working schema of the involved process. In addition, process_set_working_schema ( nil, sequence of previous SDSs ) could be executed in the context of the involved process, possibly producing EXPLOIT_SCHEMA errors. (2) as already mentioned above, the call of PROCESS_SET_WORKING_SCHEMA for another process is not the appropriate time to check the EXPLOIT_SCHEMA rights since the discretionary context of the other process can be changed later. The checks must in any case be repeated within PROCESS_START. I wonder what sense it makes at all to check the EXPLOIT_SCHEMA rights during PROCESS_SET_WORKING_SCHEMA (even if done in the correct discretionary context). So the error can as well be removed (if the calling process does not set its own working schema). -------------------- DI-5040/2 !sender Barry Bird !date 1995-08-21 Proposed Resolution: (1) 13.2.12(19) should be changed to: "If /process/ is the calling process: ACCESS_ERRORS (SDS with name in /sds_sequence/, ATOMIC, READ, EXPLOIT_SCHEMA)" This has the effect of correctly adding mandatory as well as discretionary access checks. EXPLOIT_SCHEMA permission should also be required for PROCESS_SET_WORKING_SCHEMA if the process is not the calling process i.e. is in the READY state, and should be done in terms of the effective groups of the new child process. The check must in any case also be done at PROCESS_START (or PROCESS_CREATE_AND_START), in the context of the new process. Its effective groups can differ from those of the calling process in 4 ways: - the adopted user group of the new process can be changed while it is in the READY state; - the program group membership of the static context may differ; - the supergroups of the adopted user group will in general change with the user group; - likewise for the supergroups of the program group. This means that discretionary access checks in terms of the caller's effective groups cannot be guaranteed to be the same as those in terms of the new process's effective groups for either PROCESS_START or PROCESS_CREATE_AND_START (which provides no opportunity to change the adopted user group). I propose that a new error is added to both these operations: For PROCESS_CREATE_AND_START, add: For each SDS /sds/ which is the destination of a "sds_in_working_schema" link from /process/: DISCRETIONARY_ACCESS_IS_NOT_GRANTED_TO_PROCESS (/new_process/, /sds/, ATOMIC, EXPLOIT_SCHEMA) For PROCESS_START, add to (20) [note that link name "in_working_schema_of" should be "sds_in_working_schema"]: DISCRETIONARY_ACCESS_IS_NOT_GRANTED_TO_PROCESS (/process/, /sds/, ATOMIC, EXPLOIT_SCHEMA) and also to PROCESS_SET_WORKING_SCHEMA: If /process/ is not the calling process: DISCRETIONARY_ACCESS_IS_NOT_GRANTED_TO_PROCESS (/process/, SDS with name in /sds_sequence/, ATOMIC, EXPLOIT_SCHEMA) The error should be defined in Appendix C thus: DISCRETIONARY_ACCESS_IS_NOT_GRANTED_TO_PROCESS (process, object, scope, permission) "Process /process/ does not have the atomic or composite right (according to /scope/) /permission/ to the object /object/." There is no need to change any of the SDS_IMPORT... operations. -------------------- !discussion DI-5040/3 !sender Udo Kelter !date 1995-08-21 >DI-5040/1 >Proposed Resolution: > >(1) 13.2.12(19) should be changed to: > >"If /process/ is the calling process: > ACCESS_ERRORS (SDS with name in /sds_sequence/, ATOMIC, READ, > EXPLOIT_SCHEMA)" > I think we agreed at some earlier TGEP or TGOO meeting that we should allow implementors to either cache all Information about the types in an SDS in the contents of an SDS object (as Transtar's implementation does) or not, i.e. to scan the metabase (as H-PCTE does). This can be done by adding the following implementation-specific error: If /process/ is the calling process: ACCESS_ERRORS (SDS with name in /sds_sequence/, COMPOSITE, READ, EXPLOIT_SCHEMA) > >I propose that a new error is added to both these operations: > >For PROCESS_CREATE_AND_START, add: > >For each SDS /sds/ which is the destination of a >"sds_in_working_schema" link from /process/: >DISCRETIONARY_ACCESS_IS_NOT_GRANTED_TO_PROCESS (/new_process/, /sds/, > ATOMIC, EXPLOIT_SCHEMA) o.k., but I suggest to further add implementation-specific error: For each SDS /sds/ which is the destination of a "sds_in_working_schema" link from /process/: DISCRETIONARY_ACCESS_IS_NOT_GRANTED_TO_PROCESS (/new_process/, /sds/, COMPOSITE, EXPLOIT_SCHEMA) > >For PROCESS_START, add to (20) [note that link name >"in_working_schema_of" should be "sds_in_working_schema"]: > >DISCRETIONARY_ACCESS_IS_NOT_GRANTED_TO_PROCESS (/process/, /sds/, > ATOMIC, EXPLOIT_SCHEMA) as above, add implementation-specific error: For each SDS /sds/ which is the destination of a "sds_in_working_schema" link from /process/: DISCRETIONARY_ACCESS_IS_NOT_GRANTED_TO_PROCESS (/new_process/, /sds/, COMPOSITE, EXPLOIT_SCHEMA) > >and also to PROCESS_SET_WORKING_SCHEMA: > >If /process/ is not the calling process: > DISCRETIONARY_ACCESS_IS_NOT_GRANTED_TO_PROCESS (/process/, SDS with > name in /sds_sequence/, ATOMIC, EXPLOIT_SCHEMA) I am not sure about this. As explained above, one will typically ignore this error since the discretionary context con the other process can change before it is started. The problem is that this error can ``hide'' other errors. This error should have lowest priority of being raised (e.g. only if SDS_WOULD_APPEAR_TWICE_IN_WORKING_SCHEMA does not apply), but there are no means to specify such a priority. Maybe this error should be dropped completely. > >The error should be defined in Appendix C thus: > >DISCRETIONARY_ACCESS_IS_NOT_GRANTED_TO_PROCESS (process, object, >scope, permission) >"Process /process/ does not have the atomic or composite right >(according to /scope/) /permission/ to the object /object/." > >There is no need to change any of the SDS_IMPORT... operations. no. Why do you mention this? --- another point: The error SDS_IS_UNDER_MODIFICATION is checked in PROCESS_START, but not in PROCESS_CREATE_AND_START. That seems to be an ommission. I suggest to add in 13.2.2 PROCESS_CREATE_AND_START (similar to 13.2.13(20)): (..) For each SDS sds which is the destination of an "in_working_schema_of" link from process: ACCESS_ERRORS (sds, ATOMIC, SYSTEM_ACCESS) SDS_IS_UNDER_MODIFICATION (sds) Furthermore, the error SDS_IS_UNKNOWN must be added to PROCESS_START and PROCESS_CREATE_AND_START, e.g. in the form: (..) For each SDS sds which is the destination of an "in_working_schema_of" link from process: SDS_IS_UNKNOWN (sds) ---- PROCESS_SET_WORKING_SCHEMA has the error VOLUME_IS_FULL, this due to the creation of the in_working_schema_of links (which are designation links) Their ``reverse'' links (type: in_working_schema_of) are only created when the process is started. If we do not assume a special implementation for the link type in_working_schema_of, i.e. it is really handled like a normal link, then PROCESS_START and PROCESS_CREATE_AND_START must get the additional error VOLUME_IS_FULL. However, if we assume a special implementation for the link type in_working_schema_of (which is quite likely because these links cannot really be created on read-only volumes) there must be a restriction that user-defined attributed cannot be applied to these link types (this probably applies to all usage designation links). -------------------------------------------------------------------------- !identifier EP-5041 !status unresolved !sender Richard Stuckey/ICL !date 1995-01-17 !clause Part 2/24.1(4) !title Inconsistencies in C binding limit names !comment [1] The limit name PCTE_DELTA_ACCOUNT_DURATION is out of place - according to part 1/24.3.1(2) it should follow PCTE_MAX_ACCOUNT_DURATION. [2] The limit names PCTE_MAX_KEY_SIZE, MAX_LINK_REFERENCE_SIZE, and MAX_NAME_SIZE are missing. [3] There is an extra limit name MIN_NATURAL_ATTRIBUTE. -------------------------------------------------------------------------- !identifier EP-5042 !status unresolved !sender Richard Stuckey/ICL !date 1995-01-17 !clause Part 3/9.3(36) !title Wrong parameter name in Pcte_object.delete !comment The name of the first parameter to Pcte_object.delete should be 'origin' not 'object' (see part 1/9.3.5). -------------------------------------------------------------------------- !identifier EP-5043 !status unresolved !sender John Dawes/ICL !date 1995-01-20 !clause Part 1/13.2.5(23) !title New paragraph out of place !comment The new paragraph (23), added by EP-4023/1, would be better placed immediately after (21), which is about deletion of "process" objects. I believe that EP-4023/1 intended it to go there but the paragraph numbers got muddled. -------------------------------------------------------------------------- !identifier EP-5044 !status unresolved !sender John Dawes/ICL !date 1995-01-20 !clause Part 1/14.1(36) !title Inappropriate use of the term 'contents' !comment 14.1(36) should be rephrased as 'The associated sequences of messages of message queues ...' (message queues do not have contents). -------------------------------------------------------------------------- !identifier EP-5045 !status unresolved !sender John Dawes/ICL !date 1995-01-20 !clause Part 1/23.1.1.7(1) !title Missing comma !comment There should be a comma after 'private PCTE datatypes'. -------------------------------------------------------------------------- !identifier EP-5046 !status unresolved !sender John Dawes/ICL !date 1995-01-20 !clause Part 1/23.1.2(4) !title Forgotten capital !comment 'table 11' should be 'Table 11'. -------------------------------------------------------------------------- !identifier EP-5047 !status unresolved !sender John Dawes/ICL !date 1995-01-23 !clause Part 1/23.1.2.5(9) !title Bits missing !comment [1] In line 2, 'the type name or link name' should be 'the type name or the type name of the link name'. [2] In line 3, insert space between comma and 'and'. -------------------------------------------------------------------------- !identifier EP-5048 !status unresolved !sender John Dawes/ICL !date 1995-01-23 !clause Part 1/23.1.2.5(17) !title Erroneous number !comment 'errors' should be 'error'. -------------------------------------------------------------------------- !identifier EP-5049 !status unresolved !sender Jim Clare/ICL !date 1995-04-05 !clause Part 1/9.1.2 !title Problem with common root !comment The common root is special in that it is the only object in the object base which is allowed not to be the destination of any link with the existence property. However, the semantics of the OBJECT_DELETE and LINK_DELETE operations imply that if the last such link to an object is deleted and certain other conditions are satisfied, the destination of the link is deleted. In the case where the destination is the common root, this is somewhat anomalous - if the first link with the existence property is created to the common root, it cannot then be deleted, because the conditions for deleting the common root are not satisfied as it has outgoing existence links. Of course, if a second such link to the common root is created, the first can then be deleted. An obvious way of removing this anomaly would be to make the delete operations treat the common root as a special case. A better way might be to hide the special property of the common root by adding a new link type to the system SDS:- universe : (protected) existence link to common_root; An installation would have one such link to its common root. Thus the only object which may have the special and anomalous property of being the destination of no link with the existence property would be inaccessible (and may not even `really' exist). -------------------------------------------------------------------------- !identifier EP-5050 !status unresolved !sender Jean-Claude Grosselin/Transtar !date 1995-03-17 !clause Part 2,3/C !title Missing error One error code is missing both in the C binding and in the Ada binding. This error code is PCTE_MESSAGE_IS_NOT_A_NOTIFICATION_MESSAGE. ------------------------------------------------------------------------ !identifier EP-5051 !status unresolved !sender Richard Stuckey/ICL !date 1995-06-06 !clause Part 3/10.2 !priority high !title type references in the Ada Binding !comment Part 1/23.1.2.6(1) states that a type nominator in SDS in clauses 9 to 12 corresponds to a type name in SDS in a language binding. This has been done for the SDS update operations of 10.2 (e.g. 10.2.4) in the C Binding but not in the Ada Binding. This is a serious error as it means it is impossible to compile an SDS within a transaction using the Ada binding (type references can only be set for types visible in the working schema; an SDS can be modified only if not in the working schema; an SDS can be included in the WS only if it has no uncommitted modifications). ------------------------------------------------------------------------ !identifier EP-5052 !status unresolved !sender Jim Clare/ICL !date 1995-06-06 !clause Part 1/23.1.2(3) !title Over-generalized remark !comment The second sentence of 23.1.2(3) states: '... evaluation ... is implicitly performed by all operations in clauses 9 to 23 for unevaluated references'. However this is untrue of e.g. TYPE_REFERENCES_ARE_EQUAL (23.4.8). Suggest adding to the end of the sentence: 'except where explicitly stated in some operaitons in clause 23'. ------------------------------------------------------------------------ !identifier EP-5053 !status unresolved !sender Jim Clare/ICL !date 1995-06-06 !clause Part 2/9.2(6,7) !title Wrong parameter type in LINK_DELETE_ATTRIBUTE !comment The type of parameter /attribute/ in LINK_DELETE_ATTRIBUTE should be Pcte_attribute_name not Pcte_attribute_reference. ------------------------------------------------------------------------ !identifier EP-5054 !status unresolved !sender Udo Kelter !date 1995-07-05 !clause Part 1/9.2.9 !title Ambiguity in semantics !comment The effect of LINK_REPLACE is defined as a sequence (!?) of two other operations, namely 1. LINK_CREATE (new_origin, new_link, dest, new_reverse_key); 2. LINK_DELETE (origin, link) If I want to replace a link, but not its reverse link, new_reverse_link must be the currently existing key of the reverse link. Then LINK_CREATE will fail with error REVERSE_LINK_EXISTS. The error REVERSE_LINK_EXISTS appears also in LINK_REPLACE, but I think it is only intended for the case that there is yet another link from the destination object which has the same link name as the reverse link to be created. The ambiguity in the specs lies in the problem that the sequence of operations may not really be meant to be a sequence with all error checking (see also 9.2.9(3)). Question: is it really intended that, if I replace a link, I must also rename its reverse link? I think the answer is no. If so, the specs should be made clearer, e.g. by replacing the error 9.2.9(26) REVERSE_LINK_EXISTS by LINK_EXISTS (dest, new_reverse_key) ------------------------------------------------------------------------ !identifier EP-5055 !status unresolved !sender Udo Kelter !date 1995-07-05 !clause Part 1/general !title User-defined attributes of "object_on_volume" links !comment One of our H-PCTE users has found the following problem with H- PCTE: he has - created a private SDS my_sds - imported the link type object_on_volume from system into my_sds - created a new attribute type A in my_sds - applied A to object_on_volume in my_sds - used my_sds in the working schema - tried to read / write attribute A at object_on_volume links. The last operation failed since object_on_volume links have a special "implementation" in H-PCE, they are merely "simulated" in order to avoid the performance penalty for really creating them as normal links. Q1: The above sequence of operation calls seems to be perfectly possible according to the specs, or is there anything which would prevent it? Q2: If object_on_volume links can be extended by user-defined attributes, this would be somewhat against the intention to allow an efficient implementation of them. Thus, is there an error missing, probably in SDS_APPLY_ATTRIBUTE_TYPE? (The same problem arises with other links such as the locked_by links.) Q3: If object_on_volume links can be extended by user-defined attributes, are the values of these attributes lost if the object is moved to another volume? Appendix A Changes to clause and paragraph numbers ---------------------------------------------------- A.1 Part 1 - Language-independent Specification ------------ ECMA-149 edition 2 ISO/IEC 13719-1 (see ECMA-149 edition 3) Brief History - Table of Contents Contents 1(1-4) 1(1-4) 2(1) 1(5) 3 2 3.1(1-7) 2.1(1-7) 3.2(1-24) 2.2(1-24) 4(-,1-3,4-5,-) 3(1,2-4,-,5-8) 5 4 5.1(1) 4.1(1) 5.3(1-5) 4.2(1-5) 5.2(1-5) 5(1-5) 8.1(1-6,-,7-16) 8.1(1-6,7,8-17) 8.2.1(1-16,-,17-18,-) 8.2.1(1-16,17,18-19,20) 8.2.2(1-13,-) 8.2.2(1-13,14) 8.2.3(1-17,-) 8.2.3(1-17,18) 8.3.3(1-71,-) 8.3.3(1-71,72) 8.5.1(1-10,-) 8.5.1(1-10,11) 8.5.2(1-2,-) 8.5.2(1-2,3) 8.5.3(1-5,-) 8.5.3(1-5,6-7) 9.2.1(1-24,25-26,27-37,-,38-39) 9.2.1(1-24,-,25-35,36,37-38) 9.2.2(1-10,11,12-14,15-25) 9.2.2(1-10,-,11-13,14,15-25) 9.2.3(1-7,-) 9.2.3(1-7,8) 9.2.5(1-8,-,9-10) 9.2.5(1-8,9-10,11-12) 9.2.7(1-5,-,6-7) 9.2.7(1-5,6-7,8-9) 9.2.9(1-21,-,22-25,-,26-29) 9.2.9(1-21,22,23-26,27,28-31) 9.2.11(1-4,-,5-9) 9.2.11(1-4,5,6-10) 9.3.3(1-25,-,26-35,-,36-50) 9.3.3(1-25,26,27-36,37,38-52) 9.3.4(1-13,-,14-24,25,26-34) 9.3.4(1-13,14,15-25,-,26-34) 9.3.6(1-4,5,6,-) 9.3.6(1-4,-,5,6) 9.3.12(1-16,-,17-20,21,22) 9.3.12(1-16,17,18-21,-,22) 9.3.14(1-14,- 15-16) 9.3.14(1-14,15,16-17) 9.3.16(1-4,-,5-7) 9.3.16(1-4,5,6-8) 9.3.18(1-6,6) 9.1.18(1-6,7) 9.4.3(1-7,-,8-11,11,-,12-13) 9.4.3(1-7,8-9,10-13,14,15,16-17) 9.4.4(1-7,-,8) 9.4.4(1-7,8,9) 9.4.5(1-16,-,17-29,30-32,33-37) 9.4.5(1-16,17,18-30,-,31-35) 9.4.6(1-20,-,21-33,34-36,37-41) 9.4.6(1-20,21,22-34,-,35-39) 10.2.11(1-13,-,14-21) 10.2.11(1-13,14,15-22) 10.2.12(1-16,17-18,19-38) 10.2.12(1-16,-,17-36) 10.2.20(1-5,-,6-11) 10.2.20(1-5,6,7-12) 10.2.21(1-6,-,7,-,8-11) 10.2.21(1-6,7,8,9,10-13) 10.3.10(1-8,16) 10.3.10(1-8,9) 10.3.11(1-10,4-5,14-16) 10.3.11(1-10,11-12,13-15) 10.4.10(1-3,5) 10.4.10(1-3,4) 11.2.2(1-9,-,10-11) 11.2.2(1-9,10,11-12) 11.2.3(1-20,-) 11.2.3(1-20,21) 11.2.4(1-18,-,19) 11.2.4(1-18,19,20) 11.2.4(1-10,-,11-12) 11.2.4(1-10,11,12-13 11.2.11(1-3,9,4,6-16) 11.2.11(1-3,4,5,6-16) 12.1(1-68,-) 12.1(1-68,69) 12.2.6(1-4,5,6-15,-) 12.2.6(1-4,-,5-14,15) 13.1.3(1-7,-,8-9) 13.1.3(1-7,8,9-10) 13.1.4(1-8,-,9-91,-) 13.1.4(1-8,9-12,13-95,96) 13.2.1(1-48,49,50-63) 13.2.1(1-48,-,49-62) 13.2.13(1-14,-,15-39) 13.2.13(1-14,15-16,17-41) 13.2.15(1-22,-,23-26) 13.2.15(1-22,23-24,25-28) 13.3.7(1-43,46) 13.3.7(1-43,44) 14.1(1-34,-) 14.1(1-34,35-36) 14.2.9(1-3,-,4-5) 14.2.9(1-3,4,5-6) 15.1.2(1-10,-) 15.1.2(1-10,11) 15.1.4(1,2-7,8,-) 15.1.4(1,-,2,3) - 15.2.1(1-5) 15.2.1(1-13) 15.2.2(1-13) 15.2.2(1-6) 15.2.3(1-6) 15.2.3(1-6) 15.2.4(1-6) 17.1.2(1-10,-,11-16) 17.1.2(1-10,11,12-17) 17.1.3(1-13,-) 17.1.3(1-13,14) 17.2.3(1-11,-,12-15) 17.2.3(1-11,12,13-16) 18.2.3(1-19,-,20-27) 18.2.3(1-19,20,21-28) 19.2.4(1-16,-,17,-,18-19,-,20,21-24) 19.2.4(1-16,17,18,19,20-21,22,-,23- 26) 19.3.2(1-7,-,8,-,9-12,13,14) 19.3.2(1-7,8,9,10,11-14,-,15) 20.1.1(1-2,2,3-23) 20.1.1(1-2,3,4-24) 20.1.6(1-35,-) 20.1.6(1-35,36) 22.2.10(1-9,-,10) 22.2.10(1-9,10,11) 23.1.1.6(1-2,-,3-4,-) 23.1.1.6(1-2,3,4-5,6) 23.1.2(1-3,-) 23.1.2(1-3,4-5) 23.1.2.2(1-21,-,22,23-28,-) 23.1.2.2(1-21,22,-,23-28,29) 23.1.2.4(1-6,7,-,8-11,14-17,21,-, 23.1.2.4(1-6,-,7-8,9-12,13-16,17,18, 12-13,18-20,-) 19-20,21-23,24) 23.1.2.5(1-8,-,9-15,-) 23.1.2.5(1-8,9,10-16,17-18) 23.2 1(1-3,4) 23.2.1(1-3,-) 23.2.5(1-2,3-4,5) 23.2.5(1-2,-,3) 23.2.6(1-5,6,7) 23.2.6(1-5,-,6) 23.2.8(1-3,-) 23.2.8(1-3,4) 23.3.1(1-3,-) 23.3.1(1-3,4) 23.3.4(1-4,5,-) 23.3.4(1-4,-,5) 23.3.5(1-5,-) 23.3.5(1-5,6) 23.3.10(1-3,-) 23.3.10(1-3,4) 23.4.1(1-3,-) 23.4.1(1-3,4) 23.4.4(1-4,5,6,-) 23.4.4(1-4,-,5,6) 23.4.8(1-3,-) 23.4.8(1-3,4) B.1(1-11,-) B.1(1-11,12) B.5(1,2,3-4) B.5(1,-,2-3) C.3.1(1-19,-,20-22) C.3.1(1-19,20-21,22-24) C.4(-,1-46,-,47-92,-,93-94,-, C.4(1,2-47,48-49,50-95,96,97-98,99, 95-113,-,114-159,-,160-168,169, 100-118,119,120-165,166,167-175,-, -,170-175,176,177-259,260, 176,177-182,-,183-265,266, 261-266,-.267-309) 267-272,273-274,275-317) E D D E D.1(1-36,37,38-45) E.1(1-36,-,37-44) F Index of Error Conditions ------------------------------------------------------------------------ A.2 Part 2 - C Language Binding --------------------------------- ECMA-158 edition 2 ISO/IEC 13719-2 (see ECMA-158 edition 3) Brief History - Table of Contents Contents 1(1-2) 1(1-2) 2(1) 1(3) 3(1-2) 2(1-2) 4(1-5,6) 3(1-5,-) - 4(1) 7.2(1,-,2-9) 7.2(1,2,3-10) 7.5(1-4,-) 7.5(1-4,5) 7.7(1,-) 7.7(1,2-3) 8.2.11(1-5,-,6-7) 8.2.11(1-5,6-8,9-10) 8.5.1(1-22,23-24,25-26) 8.5.1(1-22,23-28,29-30) 8.7.2(1-10,-,11-12,-,13) 8.7.2(1-10,11-13,14-15,16-18,19) 8.7.3(1-45,46,47-48) 8.7.3(1-45,46-48,49-50) 10.2(1-25,27-38,25,39-47) 10.2(1-25,26-37,38,39-47) 10.3(1-3,-,4-11,-,12-18) 10.3(1-3,4,5-12,13,14-20) 10.4(1-4,-,5-8,-,9-17,-,18-27,-,28) 10.4(1-4,5,6-9,10,11-19,20,21-30,31- 32,33) 11.1(1-5,-) 11.1(1-5,6) 12.2(1-20,-,21) 12.2(1-20,21,22) 14.1(1,-,2-6) 14.1(1,2,3-7) 15.1(1-2,3) 15.1(1-2,-) 15.2(1-2,-,3-4) 15.2(1-2,3,4-5) 23.1(1-3,-,4-5,-,6-21) 23.1(1-3,4,5-6,7,8-23) 23.2(1-10,-,11) 23.2(1-10,11,12) 23.3(1-13,-,14) 23.3(1-13,14,14) 23.4(1-4,-,5-7,-,8-9) 23.4(1-4,5,6-8,9,10-11) ------------------------------------------------------------------------ A.3 Part 3 - Ada Language Binding ----------------------------------- ECMA-162 edition 2 ISO/IEC 13719-3 (see ECMA-162 edition 3) Brief History - Table of Contents Contents 1(1-2) 1(1-2) 2(1) 1(3) 3(1-2) 2(1-2) 4(-,1-5) 3(1,2-6) 5(1) 4(1) 5.1(1) 4(2) 5.2(1) 5(1) 7.2(1,-,2-13) 7.2(1,2,3-14) 7.4(1-3,-) 7.4(1-3,4) 8.2.8(1-6,7-8,9-20,-,21-25) 8.2.8(1-6,7-12,13-24,25,26-30) 8.4(1-104,-,105-135,136,137-142,-, 8.4(1-104,105,106-136,137-139,140- 145,146, 143-149,150,151-156,-,157-163, 147-153,154-156,157-162,163,164-170, 164,165-170,-,171-177,178, 171-173,174-179,180,181-187,188-190, 179-184,-,185-191,192,193-198,-, 191-196,197,198-204,205-207,208-213,214, 199-200) 215-218) 9.3(1-7,8-9,10-12,13-26,27-30,31, 9.3(1-7,-,8-10,-,11-14,15-17, 32-37,-,38-89) 18-23,24,25-76) 11.2(1-41,42,43-48,-,49-58) 11.2(1-41,42-44,45-50,51,52-61) 13.1(1-13,14,15-20,-,21-28,29, 13.1(1-13,14-16,17-22,23,24-31,32-34, 30-35,-,36-38) 35-40,41,42-44) 14.1(1-21,22,23-28,-,29-31) 14.1(1-21,22-24,25-30,31,32-34) 14.2(1,2,3-14,15-16,17-18,19,-, 14.2(1,-,2-13,-,14-15,-,16,17, 20-21,-,22-27) 18-19,20,21-26) 15.2(-,1-4) 15.2(1,2-5) 17.2(1,15,2-15) 17.2(1,-,2-15) 19.1(1-25,26,27-32,-,33-35) 19.1(1-25,26-28,29-34,35,36-38) 21.1(1-19,20,21-26,-,27-36,37, 21.1(1-19,20-22,23-28,29,30-39,40-42, 38-43,-,44-53,54,55-60,-,61-70, 43-48,49,50-59,60-62,63-68,69,70-79, 71,72-77,-,78-87,88,89-94,-,. 80-82,83-88,89,90-99,100-102,103- 108,109, 95-97) 110-112) 21.2(1-29,30,31-36,-,37-49) 21.2(1-29,30-32,33-38,39,40-52) 22.1(1-14,15,16-21,-,22-24) 22.1(1-14,15-17,18-23,24,25-27) 25(1-26,27,28,-,29-45) 25(1-26,-,27,28-29,30-46) Appendix B Index of Comments ------------------------------ EP- U/R sender date clause title 4041 U Kirby 940110 1/15.1 Transaction rollback of moved obje 4068 U Kirby 940110 1/10.2.16-19 Omitted access errors from SDS_IMP 4069 U Kirby 940110 1/23.2.5,6 Confusing error returns setting ob 4071 U Kirby 940110 1/19.3.9 Insufficient checks to prevent gra 4128 R Bird 940110 1/9.3.2 Replicated objects should not be c 4227 R Stuckey 940216 2/8.2.5 Pcte_time almost unusable 4310 R Japan 940316 1/A.1 Multi-octet character set 4346 R Boudier 940224 1/10.2.1 sds_add_destination 4347 U Boudier 940224 1/10.2.2 sds_apply_attribute_type 4348 R Boudier 940224 1/10.2.5 sds_create_designation_link_type 4349 R Boudier 940224 1/10.2.7 sds_create_enumeration_attribute_ 4350 U Boudier 940224 1/10.2.11 sds_create_object_type 4351 R Boudier 940224 1/10.2.12 sds_create_relationship_type 4352 R Boudier 940224 1/10.2.16 sds_import_attribute_type 4353 R Boudier 940224 1/10.2.18 sds_import_link_type 4354 R Boudier 940224 1/10.2.19 sds_import_object_type 4355 R Boudier 940224 1/10.2.20 sds_initialise 4356 R Boudier 940224 1/10.2.21 sds_remove 4357 R Boudier 940224 1/10.2.23 sds_remove_type 4358 R Boudier 940224 1/10 SDS Usage Operations 4359 U Boudier 940224 1/11.2.6 device_remove 4360 R Boudier 940224 1/11.2.11 volume_mount 4361 R Boudier 940224 1/11.2.12 volume_unmount 4362 R Boudier 940224 1/12.1 Files, Pipes, Devices Operations 4363 R Boudier 940224 1/12.2.6 contents_open 4364 U Boudier 940224 1/12.2.7 contents_read 4365 R Boudier 940224 1/12.2.8 contents_seek 4366 R Boudier 940224 1/12.2.9 contents_set_position 4367 R Boudier 940224 1/12.2.10 contents_set_properties 4368 R Boudier 940224 1/12.12 contents_write 4369 U Boudier 940224 1/13.2.1 process_create 4370 U Boudier 940224 1/13.2.2 process_create_and_start 4371 U Boudier 940224 1/13.2.4 process_interrupt_operation 4372 U Boudier 940224 1/13.2.13 process_start 4373 U Boudier 940224 1/13.2.15 process_terminate 4374 U Boudier 940224 1/13.2.17 process_wait_for_any_child 4375 U Boudier 940224 1/13.2.18 process_wait_for_child 4376 U Boudier 940224 1/13.3.1 process_adopt_user_group 4377 U Boudier 940224 1/13.3.7 process_set_user 4378 U Boudier 940224 1/13.5.1 process_add_breakpoint 4379 U Boudier 940224 1/13.5.2 process_continue 4380 U Boudier 940224 1/13.5.3 process_peek 4381 U Boudier 940224 1/13.5.4 process_poke 4382 U Boudier 940224 1/13.5.5 process_remove_breakpoint 4383 U Boudier 940224 1/13.5.6 process_wait_for_breakpoint 4384 U Boudier 940224 1/14.1 Message Queue Concepts 4385 U Boudier 940224 1/14.2.2 message_peek 4386 U Boudier 940224 1/14.2.9 queue_handler_enable 4387 U Boudier 940224 1/14.2.11 queue_restore 4388 U Boudier 940224 1/14.2.13 queue_set_total_space 4389 U Boudier 940224 1/18.2.2 workstation_create 4390 U Boudier 940224 1/18.3.1 contents_copy_from_foreign_system 4391 U Boudier 940224 1/18.3.2 contents_copy_to_foreign_system 4392 U Boudier 940224 1/19.2.1 group_get_identifier 4393 U Boudier 940224 1/19.2.4 object_set_acl_entry 4394 U Boudier 940224 1/19.3.4 program_group_add_member 4395 U Boudier 940224 1/19.3.5 program_group_add_subgroup 4396 U Boudier 940224 1/19.3.8 user_group_add_member 4397 U Boudier 940224 1/19.3.9 user_group_add_subgroup 4398 U Boudier 940224 1/20.1.8 Built-in Policy Aspects 4399 U Boudier 940224 1/21.1.1 Audit Files 4400 U Boudier 940224 1/22.1.2 22.1.2 4401 U Boudier 940224 2/C New errors added to ECMA-149 4402 U Boudier 940224 2/C New errors added to ECMA-158 4403 U Boudier 940224 1/D.1 System SDS changes 4404 U Daeberitz 940224 1/9.1.1 Num of incoming links 4409 U Kelter 940505 1/9.3.20 Navigate access to volume object 4410 U Bird 940510 1/23.1.2.6 4411 U Davis 940509 1/7 Status of clause 7 4412 U Davis 940509 2/7 Status of clause 7 4413 U Davis 940509 3/7 Status of clause 7 4416 U Bird 940614 1/16.1.10 Locks Table Inconsistence 4417 U Bird 940629 1/23.1.2.5,C.4 Invalid Type Handles 4418 U Bird 940629 1/23.1.2.5,C.4 Type Handles for an SDS not in WS 4419 U Bird 940629 1/23.1.2.5 Invalid Type Handles 4420 U Bird 940629 1/23.1.2.3 Invalid Type Handles 4421 U Bird 940629 1/10.4,C.4 Invalid Type Handles 4422 U Bird 940629 1/23.3.8 Invalid Type Handles 4423 U Bird 940629 1/C.4 Invalid Type Handles 5001 U Stuckey 940801 3/7.2 Poor example of package hierarchy 5002 U Bird 940815 1/23.1.2.5 Correction to EP-4061 5003 U Kaikow 941001 1/general Style 5004 U Bird 941109 1/23.1.2.4 Evaluation of Link references 5005 U Bird 941109 1/23.3.5 LINK_REFERENCE_GET_NAME 5006 U Bird 941109 1/23.3.8 LINK_REFERENCE_SET 5007 U Bird 941109 1/C.4 text is wrong 5008 U Bird 941109 1/C.3.3 should be removed 5009 U Bird 941109 1/19.2.4,C.4 two 'control would not be granted' 5010 U Bird 941109 1/C.4 wording should also be changed 5011 U Bird 941109 1/9.3.12 designation links with deleted des 5012 U Bird 941109 1/C.4 TYPE_IDENTIFIER_SYNTAX_IS_WRONG is 5013 U Bird 941109 1/13.2.1 Access rights for preexisting grou 5014 U Bird 941109 1/13.2.1 References to SDS 'security' 5015 U Bird 941109 1/9.4.3 Error in ACCESS_ERRORS 5016 U Bird 941109 1/9. error OBJECT_CANNOT_BE_STABILIZED 5017 U Bird 941109 1/16.1.7 access rights needed to establish 5018 U Bird 941109 1/16.1.5 sounds like rubbish 5019 U Bird 941109 1/13.2.18 Missing case in WAIT_FOR_CHILD 5020 U Bird 941109 1/12.2.10 Problems with Contents_set_proper 5021 U Bird 941109 1/16 object_on_volume links are subject 5022 U Bird 941109 1/23.4.3,4,6 error TYPE_IS_NOT_VISIBLE should b 5023 U Bird 941109 1/23.1.2.5 More errors for type references 5024 U Bird 941109 1/23.4.3 TYPE_REFERENCE_GET_IDENTIFIER must 5025 U Bird 941109 1/23.4.4 TYPE_REFERENCE_GET_NAME must evalu 5026 U Bird 941109 1/C.4 Identical errors 5027 U Bird 941109 1/10.4 Conflict of errors 5028 U Bird 941109 2/8.6 Alignment 5029 U Bird 941109 2/8.2.11,25.1 The same error has three different 5030 U Bird 941109 2/8.2.10 table about sequences is still wro 5031 U Bird 941109 2/8.3 Pcte_reference_* should be Pcte_ob 5032 U Bird 941109 2/8.2.5 Move the C code 5033 U Bird 941109 2/8.7.2 Misleading insertion 5034 U Bird 941109 3/9.3 Misleading insertion 5035 U Dawes 941126 1/general Minor editing errors 5036 U Dawes 941126 1/C.4 Redundant error conditions 5037 U Dawes 941126 1/Index of Err Missing references 5038 U Dawes 941126 1/General Wrong paragraph numbers 5039 U Stuckey 941216 1/23.3.8 Link reference problem 5040 U Kirby 950116 1/13.2.12,13 Serious error in PCTE security 5041 U Stuckey 950117 2/24.1(4) Inconsistencies in C binding limit 5042 U Stuckey 950117 3/9.3(36) Wrong parameter name in Pcte_objec 5043 U Dawes 950120 1/13.2.5(23) New paragraph out of place 5044 U Dawes 950120 1/14.1(36) Inappropriate use of the term 'con 5045 U Dawes 950120 1/23.1.1.7(1) Missing comma 5046 U Dawes 950120 1/23.1.2(4) Forgotten capital 5047 U Dawes 950123 1/23.1.2.5(9) Bits missing 5048 U Dawes 950123 1/23.1.2.5(17) Erroneous number 5049 U Clare 950405 1/9.1.2 Problem with common root 5050 U Grosselin 950317 2,3/C Missing error 5051 U Stuckey 950606 3/10.2 type references in the Ada Binding 5052 U Clare 950606 1/23.1.2 Over-generalized remark 5053 U Clare 950606 2/9.2 Wrong parameter type in LINK_DELET 5054 U Kelter 950705 1/9.2.9 Ambiguity in semantics 5055 U Kelter 950705 1/general User-defined attributes of "object