Subject: WG11/N361 (SC22/N1354)- Summary of Voting on LID

From: Willem Wakker <[email-masked]>
Date: Wed, 05 May 93 12:58:09 N

Received by fax: SC22/N1354, Summary of Voting and Comments on LID (11404.1)

Result:
	P Members supporting CD registration without comments: 8
		[Brazil, China, Denmark, Finland, France, Italy,
		 Netherlands, Romania]

	P Members supporting CD registration with comments: 2
		[New Zealand, UK]

	P Members not supporting CD registration: 2
		[Sweden, USA]

	P Members abstaining: 2
		[Canada, Germany]

	P Members not voting: 7

The New Zealand comments are:
	The absence of the value UNDEFINED in the domain of all types
	specified in this draft is regretted. It is considered that while
	few current languages have such a requirement, such a requirement
	will become more common in the future as greater use is made of
	formal methods in all aspects of Information Technology.

	While the need for a concrete syntactic from for the draft is
	obvious, it is surprising that an abstract syntax has not been
	defined so that proof of equivalence in the mapping from language
	definitions/bindings can be made more readily.

The UK comments were (on paper) distributed at the WG11 meeting last week,
can somebody from the UK make these available to the SC22WG11 list?

The comments from Sweden are:
1.	In clause 2: after "ISO 8601:1988" add "including Technical
	Corrigendum 1:1991".

2.	All character names should follow JTC1/SC2 standards, particularly
	ISO/IEC 10646-1 (presently being printed). I refer to Annex J
	Rule 1: "By convention, only Latin capital letters A to Z,
	space, and hyphen shall be used fro writing the names of
	characters."

Follows a list of replacements:
		"apostrophe-mark"	-> "QUOTATION MARK"
		"hyphen mark"		-> "HYPHEN-MINUS"
		"open-brace mark"	-> "LEFT CURLY BRACKET"
		"close-brace mark"	-> "RIGHT CURLY BRACKET"
		"open-bracket mark"	-> "LEFT SQUARE BRACKET"
		"close-bracket mark"	-> "RIGHT SQUARE BRACKET"
		"vertical-stroke mark"	-> "VERTICAL LINE"
		"full-stop mark"	-> "FULL STOP"
		"equal-sign"		-> "EQUALS SIGN"

Clause 7.1 under iii): "ISO 10646:1992" ->  "ISO/IEC 10646-1:1993"

Clause 8.1.4 Note 4: "Latin alphabet" -> "Latin alphabet No. 1"

Clause 8.1.6 under value-syntax: "a single decimal point" -> 'the letter "T"
and/or a single decimal  point'. Explanation: according ISO 8601  clause 5.4.1,
a time-designator "T" shall be used between date and time in a combined date
and time representation.

Note WFW: These comments seem all to fall in the category 'editorial'.
However, there is no indication on how to change the NO vote to a YES vote.
I will contact ITS (Swedisch standardizationorganization) to find out.

The comments from the US are appended. To change the NO to a YES, if the
to comments designated Major are satisfactory resolved.

U.S. comments on LI Datatypes (ISO CD 11404.2)

The U.S. votes NO on the progression of CD 11404 to DIS.
Our vote will be changed to YES if the two comments
designated Major below are satisfactorily resolved.

Issue: 1
Subject: Define the useful model of Array-types
Type: Major
Clauses: 8.4.4 and 8.4.5
Xref: RPC 9.5.2.3 and X3T5.5/93-020

Rationale: The Sequence and Array types of LID cover at
least the following conceptually distinct datatypes:

Fixed-length single index - vector.   What must be
preserved is the ordering of the components, indexing
could be off by 1 in language mappings without serious
consequences.

Variable-length single index - sequence (values of
different lengths). What must be preserved is the
ordering of the components, indexing is effectively
ordinal, so any language convention is adequate.

Fixed multiple indices - matrix/map. What must be
preserved is dimensionality (shape) and ordering within
each dimension. Preservation of indices is desirable, but
not required. Total linear ordering is not conceptually
meaningful.

Conformant multiple indices -matrix/map template. This is
a template, not a datatype, and is satisfied by any
datatype which can "conform" to the template syntax.
Alternatively this could be represented as a sequence of
sequences in which values must conform to some unstated
rules. The conformant array syntax is used to facilitate
mapping to programming languages.

In addition, the following two "datatypes" exist in
Fortran:

Multiple indices of which the last is variable. This
appears to be properly modelled as a sequence of (array
of n-1 dimensions).

Reshaped arrays, in which the size is constant, but the
indexing
and dimensionality is different between the caller and
the called procedure. This appears to be properly
modelled as a sequence, since the ordering of ALL the
elements must be shared, while indexing is a local
matter.

Finally the notion "slicing" has been suggested as an
important concept for LIPC/RPC. Conceptually the
interface argument type of a "slice" is that of the
result of the slicing operation, which is an "ordinary"
array-type, and the means of generation of the "sliced
value" is a caller-only (marshalling) issue. In practice,
where the slice is implemented by a subscripting
procedure ("thunk") provided by the caller and invoked by
the called procedure, that should be declared to the
called procedure by an annotation.

What is clear from the above is that the notion that an
array is a Map from one or more index-types to the
element-types is a poor characterization of the semantics
of the array-type when it is mapped into multiple
programming languages. The index-value to element-value
association does NOT have to be preserved. It is at best
desirable in ONE of the above cases. That the access is
indexed (6.8.5) is an important property, and the
dimensionality and the ordering of values WITHIN a
dimension must be preserved.

Moreover, the only distinction between sequence and array
as parameter types seems to be that the size of an array
dimension must be formally specified (hence all of the
dependent-value stuff) while the size of a sequence value
is somehow implicitly carried in the value. Noting that
only values can actually be passed, this distinction
doesn't seem to be useful. Thus LIPC does not need both
Sequence and Array.

Proposed Change:

a. Merge Sequence and Array.

b. Explain the meaning of Array in terms of the
CARDINALITY of the index-types, and the ORDINAL mapping
from index-values to array elements.

c. Devise a notation for variable-length dimensions and a
standard mechanism for handling length parameters that
are effectively supplied at runtime. Size parameters are
part of the value of an array-type which has one or more
variable dimensions, just as they are of a variable
length sequence.

Issue: 2

Subject: Make Table model support SQL model
Type: Major
Clauses: 8.4.6
Xref: SC21/WG3 N1452 and X3T2/92-111

Rationale: The existing table-type is too restrictive to
support the SQL table model and can be generalized to
support the SQL model as well as the notion currently
supported by LID.

Proposed Change: Redescribe Table as follows:

Description: Table generates a datatype, called a table
datatype, whose values are associations among values in
the product space of one or more field datatypes.

Syntax: table-type = table "(" field-list ")" .
Components: (same as Record).
Values: the value space of Table(field-list) is identical
to the value space of Bag(Record(field-list)).
Value-syntax:
table-value = empty-value | "(" table-entry { "," table-
entry } ")"
table-entry = record-value .

Properties: non-numeric, unordered, exact if and only if
all field-types are exact, heterogeneous, variable size,
no uniqueness, no ordering, access is keyed,
dimensionality is two.

Subtypes:

i) any table-type which has the same number of fields in
the field-list, the field-names correspond, and each
field-type is the same as, or a subtype of, the field-
types of the base datatype, or

ii) (as is)

Operations: Equal, Empty, Insert, Delete from Bag; Select

Select(x: table(field-list), p: procedure(in row:
record(field-list)): boolean): table(field-list) is the
table whose elements (rows) consist of exactly those rows
r of x for which p(r) = true.

Note. This would be a defined-type, but the type-
declaration syntax does not permit the parameter-list to
be a variable-length list of field-specifiers.

Issue: 3

Subject: Reword multiple repertoire explanation
Type: E
Clauses: 8.1.4
Xref:

Rationale: poor wording

Proposed Change:

Change "All repertoire identifiers ... character-set." to
"All repertoire identifiers in a given repertoire list
shall designate subsets of the same reference character-
set."

Change "only the distinct members" to "the (set) union of
the character-sets (without duplication)".

Issue: 4

Subject: Make Ordinal a defined-type
Type: minor
Clauses: 8.1.5
Xref: X3T2/93-006

Rationale: Ordinal can be completely and correctly
described in a type-declaration based on integer and such
a declaration eliminates an existing ambiguity in the
value syntax. (Is "1" an ordinal value or an integer
value?)

Proposed Change: Move the definition of the ordinal type
from clause 8.1 to clause 10.1, replacing the "syntax"
paragraph with:

Declaration: type ordinal = new integer: range(1..*); .

Issue: 5

Subject: Make Bit a defined-type
Type: minor
Clauses: 8.1.7
Xref: X3T2/93-006

Rationale: Datatype Bit is precisely Modulo(2) and should
be so declared.

Proposed Change: Move the definition of the bit datatype
from clause 8.1 to clause 10.1, replacing the "syntax"
paragraph with:

Declaration: type bit = modulo(2); .

Issue: 6

Subject: Inappropriate characterizing operations for
choice
Type: minor
Clauses: 8.3.1
Xref: WG11-2.9

Rationale: The choice-type, as currently described, is
one of two useful models of the choice-type and is that
which maps most readily to programming languages and to
existing RPC implementations. However, the value model
(tag-value, alternative-value) is not supported correctly
by the characterizing operations.

Proposed Change:

a. Replace the IsType operation with:

Discriminant(x: choice (tag-type) of (alternative-list)):
tag-type is the tag-value of the value x;

b. Rephrase the definition of Cast as:

If the tag-value of x selects an alternative whose
alternative-type is type, then that value of type which
is the alternative-value of x, else undefined;

c. Rephrase the definition of Equal as:

If Discriminant(x) and Discriminant(y) select the same
alternative, then type.Equal(Cast.type(x), Cast.type(y)),
where type is the alternative-type of the selected
alternative and type.Equal is the Equal operation on
datatype type, else false.

d. Add

Note: the operation Discriminant is a conceptual
operation which reflects the ability to determine which
alternative of a choice-type is selected in a given
value. Any equivalent mechanism is satisfactory. When a
choice-value is moved between two contexts, as between a
program and a data repository, representation of the
chosen alternative is required, and most implementations
explicitly incorporate the tag-value.

Note. The other useful model is choice(field-list) where
exactly one field is present in any given value and the
means of discrimination is not specified. In this model,
IsField.field(x: choice(...)): boolean = true
if the designated field is present in the value x,
replaces Discriminant, with corresponding changes to the
other characterizing operations. It is recognized that
this model is mathematically more elegant (the Or-graph
to match the And-graph of the fields in Record), but in
practice, either IsField is not provided (which makes all
operations user-defined) or IsField is implemented by
tag-value (which makes IsField equivalent to
Discriminant).

Issue: 7

Subject: Relationship of pointers to boxes
Type: E
Clauses: 8.3.2
Xref: X3T2/92-112

Rationale: Many comments suggest that the relationship
between the LID pointer datatype and the language notion
"variable" and the implementation notion "memory cell"
are confused.

Proposed Change: Add the following Note:

Note - The hardware implementation of the "means of
reference to" a value of the element-type is usually a
memory cell or cells which contain a value of the
element-type. The memory cell has an "address" which is
the "value of the unspecified state datatype". The memory
cell physically maintains the association between the
"address" (pointer-value) and the element-value which is
stored in the cell. The Dereference operation is
conceptually applied to the "address" (pointer-value) but
is implemented by a "fetch" from the memory cell. Thus in
the computational model used here, the "address" and the
"memory cell" are not distinguished: a pointer-value is
both the cell and its address, because the cell can only
be manipulated through its address. The cell, which is
the pointer-value, IS distinguished from its contents,
which is the element-value. The notion "variable of
datatype T" appears in programming languages and is
usually implemented as a cell which contains a value of
type T. Language standards often distinguish between the
"address of the variable" and the "value of the variable"
and the "name of the variable", and one might conclude
that the "variable" is the cell itself. That conclusion
is not useful. In the computational model used here, the
"address of the variable" is a value of LI datatype
"pointer to (T)", while the "value of the variable",
meaning the contents of the cell, is a value of LI
datatype T, and all operations on the "variable" must
operate on one of those two values. This notion is
further elaborated in DIS nnnn: LIPC, which relates
pointer-values to the "boxes" (or "cells"), which are
elements of the state of a running program.

Issue: 8

Subject: Remove Switch
Type: minor
Clauses: 10.1.1
Xref: X3T2/93-006

Rationale: The syntax for type-declarations no longer
supports Switch, and it seems to be nothing more than a
renaming of boolean and its values.

Proposed Change: Delete clause 10.1.1.

Issue: 9

Subject: Rename "Cardinal" "NaturalNumber".
Type: minor
Clauses: 10.1.2
Xref: X3T2/93-006

Rationale: The term natural number appears several times
in CD 11404, while the term "cardinal" never does. While
"cardinal" is one proper mathematical term, "natural
number" is equally acceptable in mathematics and much
more common in computer science, information analysis,
etc.

Proposed Change: Change all occurrences of "Cardinal" to
"NaturalNumber".

Issue: 10

Subject: Provide guidance on "identifier" datatypes and
"syntactic strings"
Type: minor
Clauses: 10.1.4
Xref: X3T2/93-006

Rationale: Languages like LISP and Prolog which have
dynamic evaluation of certain kinds of "syntactic
strings" think of these as having a datatype. Many
special-purpose languages have "variables" or "values"
which are represented as character-strings, but have
important semantic properties. It appears that such
objects must be character-strings when manipulated by
other languages.

Proposed Change: Add a Note to clause 10.1.4 (Character-
string) showing an example of declaring a "character-
string" datatype which has important semantic properties,
as was done for Prolog (in Tampere).

Issue: 11

Subject: Remove "Currency"
Type: minor
Clauses: 10.1.6, 8.1.10
Xref: X3T2/93-006

Rationale: This type definition is only appropriate to
some major international currencies. It is inappropriate
for Japan, Italy, Spain, Mexico, to name but a few. An
example for some appropriate currency should appear under
Scaled.

Proposed Change:

a. Remove clause 10.1.6.

b. Add Example: type dollars = scaled(10,2); with
appropriate explanation in 8.1.10.

Issue: 12

Subject: Rename "Interval"
Type: minor
Clauses: 10.1.7
Xref: X3T2/93-006

Rationale: "Interval" is a valid datatype in Ada, Modula
and many real-time applications regardless of language.
But the meaning is "time-interval" not "distance".

Proposed Change: Replace all occurrences of "Interval"
with "TimeInterval".

Issue: 13

Subject: Remove "distinguished name"
Type: minor
Clauses: 10.1.11
Xref: X3T2/93-006

Rationale: RPC asked for this datatype but it does not
appear in the RPC standard. While it is apparently
defined by a recently adopted ISO standard (Directory
Services), it is only one of many ISO standard naming
syntaxes. Its inclusion in LID does not seem to meet any
immediate need.

Proposed Change: Remove clause 10.1.11.

Issue: 14

Subject: Remove cyclic-enumerated
Type: minor
Clauses: 10.2.3
Xref: X3T2/93-006

Rationale: This datatype is not common in the sense that
it appears in many (any?) programming languages or many
interfaces. Moreover, it serves only to modify a
characterizing operation of enumerated-types and that
very slightly.

Proposed Change: Delete clause 10.2.3.

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Willem Wakker					 email: <[email-masked]>
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
ACE Associated Computer Experts bv		   ...!mcsun!ace!willemw
van Eeghenstraat 100				    tel: +31 20 6646416
1071 GL  Amsterdam				    fax: +31 20 6750389
The Netherlands					     tx:  11702 (ace nl)
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee