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. ----------------