From listadm Wed Jan 15 04:40:20 2003 Received: from ssdo.org (ssdo.org [192.104.18.141]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id EAA59327 for ; Wed, 15 Jan 2003 04:40:20 +0100 (CET) (envelope-from frank@farance.com) Received: from roadshow (proxy5.farance.com [192.104.18.5] (may be forged)) by ssdo.org (8.9.3/8.9.3) with SMTP id WAA10029 for ; Tue, 14 Jan 2003 22:40:26 -0500 (EST) Message-Id: <3.0.5.32.20030114223946.033de7d0@farance.com> X-Sender: frank@farance.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 14 Jan 2003 22:39:46 -0500 To: "ISO-IEC/JTC1/SC22/WG11" From: Frank Farance Subject: Latest draft of ISO/IEC 11404 revision (resend) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" [I'm resending this E-mail because I didn't see the message on the E-mail reflector. The original E-mail had an attachment. I've put it up on my web site at: http://farance.com/standard/iso/11404/iso_iec_11404_draft--20030113.doc Hopefully, this E-mail will go through. -FF] WG11 Folks- Happy New Year! About 3 months ago, I finished preparing a draft of the revision of ISO/IEC 11404 (previously called "Language Independent Datatypes", now called "General Purpose Datatypes"). I sent it to Willem and several others to get some review. I have made improvements and corrections, as suggested. I am sending this to WG11 to get wider review (see attachment). Below, please find the "11404 charter" document that we have been using for the revision (see discussion in early 2001 in E-mail logs). Regarding the "charter", the following features are left to be added: - Use ISO/IEC EBNF standard syntax - Convert to ISO document template - Alignment with ISO/IEC 10967 LIA real and complex - Alignment with recent 2002 revision of ASN.1 (i.e., add annex on relationship to ASN.1) - Add normative annotation syntax for particular data representation formats - Add normative annotation syntax for supplying GUID/UUID to data element definition - Add namespace semantics (taken from C/C++/Javascript) - Add annex on relationship to ISO/IEC 11179-3 (metadata registries) so that 11404 "programs" have a predefined binding to 11179-3 metadata attributes I need help with the 10967 alignment, so please provide feedback. Probably the area that will spark the most discussion is the "class" capability (your comments are welcome!). Here's a summary: - The framework for "class" is based on the lower level conceptual framework of C++, which is: data structure + member functions. - The inheritence capability is performed by an "import" feature (i.e., import all the data elements and methods from another datatype/class definition), with an "override" capability (i.e., methods may be overridden with new definitions -- a labelling issue). - Regarding overloading, this is an issue that can worked through the namespace wording. - Right now, there is no attempt to support access restriction (e.g., public, private, etc.). If this is desired, I can add it in. I believe the document is worth reviewing because, aside from the minor improvements above, the main features of the revision are complete. I would like to get consensus so that we can submit the text for committee draft ballot. Please send comments to the WG11 E-mail reflector, but no later than 2003-01-31. I look forward to receiving your comments and I thank you in advance for your review. Frank Farance Project Editor for ISO/IEC 11404 Revision ---------------------------------------------------------------------- Revision Charter for ISO/IEC 11404 Language Independent Datatypes Date: 2001-04-24 Purpose of 11404 Revision: Provide enhancements to the use of ISO/IEC 11404 as a data type nomenclature reference for current programming languages, interface languages and data representation languages, specifically Java, IDL, Express, and XML. The following are improvements are in no particular order. 1. Change Title, Introduction, Scope, and Conformance sections The current 11404 standard can be misleading because readers may believe: (1) it is only useful for programming languages, and (2) programming language bindings are the only useful purpose for 11404. These sections should be revised to include the expanded possibilities of 11404, such as data specification for a variety of applications and systems. The Title of the standard should be reviewed, too, so that a more current title might be considered. 2. Support for Semi-Structured and Unstructured Data Aggregates Semi-structured data and unstructured data includes aggregates where datatyping and navigation may be unknown or unspecified in advance. For example, some systems permit "discovery" (or "introspection") of data. In some cases, the datatype may be unknown in advance (e.g., a compilation time), but may be discovered and process at runtime (e.g., via datatype libraries or metadata registries). 3. Support for Data Longevity, Versioning, and Migration There is a need to support, from a datatyping perspective, obsolete/reserved elements/vocabulary. Data elements may come and go. Particular values in "state" and "enumeration" datatypes may come and go. Marking features as "obsolete" allows processing, compilation, and runtime systems to "flag" or diagnose old (deprecated) features, while still maintaining compatibility (==> supporting transitions from past to present). Similarly, marking features as "reserved" allows processing, compilation, and runtime systems to "flag" or diagnose potential incompatibilities with future systems (==> supporting transistions from present to future). 4. Extensibility of Types and Value Spaces There is a need to support some kind of extensibility concept. For example: (1) an 11404 specification of an aggregate contains the elements A and B; (2) an application creates an aggregate with the elements A, B, and C; (3) is the application's "extensions" of the aggregate acceptable/conforming with the 11404 specification in #1? The answer to #3 is dependent upon the intent and design of the specification in #1: in some cases extensions are permitted, in some cases extensions are not permitted. The extensibility concept would allow the user of 11404 to describe the kind of extensions permitted. This feature is particularly important in (1) data conformance, (2) application runtime environments that permit "discovery" or "introspection". 5. Alignment of ISO/IEC 10967 Language Independent Arithmetic The 11404 standard should be realigned with the LIA standards, including the "real" and "complex" datatypes. 6. Adding "object" and "object reference" Concepts This would include adding the concept of "object" and "object reference", with possible consequences for the "pointer" and (OSI) "object identifier" types. These features would describe the object concept that is now supported in many programming environments. There should be some support for describing inheritance and object methods. 7. Data Represention A common data interchange problem is describing data representation along with the datatypes. It would be very useful to incorporate these kind of features in an LID specification of, say, a data model. Currently, Annex C discusses these possibilities, but Annex C does not give guidance on how to write these data representation specifications in a consistent, standard syntax. This improvement would provide a consistent syntax. As a side note, IEEE 1596.5 has done reasonable job of cataloging the integer datatypes (8, 16, 32, 64, 128 bits; ones and twos complement; various alignments) and real datatypes (32, 64, 80, 128 bits; IEEE/IEC, IBM, VAX, Cray; various alignments). The ISO/IEC 10646 character encodings should be incorporated. The C/C++ notions of wide character and multi-byte strings should be incorporated. With these data representation features, it will be possible to write language independent specifications of data structures, e.g., network packets, shared memory blocks, and so on. 8. Explicit Support/Mappings for Standards/Specifications The following would be included in, say, a mapping annex: - Alignment with types in ISO 14750 (ODP IDL) - Alignment with types in ISO 10303-11 (Express) - Alignment with types in ISO 8824 (ASN.1) - Alignment with types in XML Schema 9. Namespace Definition and Semantics The current 11404 standard does not specify the naming spaces of identifiers. This problem could be address by adopting a conceptual model that is common to one or more environments (e.g., programming languages) and then, separately, choosing a binding syntax. 10. Referenced Documents The following should be reviewed during the revision process: - ISO/IEC 8824 and 8825 (ASN.1) - ISO 14750, Open Distributed Processing -- Interface Definition Language (IDL) - ISO 11303-11, and ISO CD 10303-11.2, Data modeling language Express - XML specification - XML Schema specification - OMG Unified Modeling Language - OMG XMI In addition, the following new or revised standards should be reviewed during the revision process: - ISO/IEC 9899 C Programming Language - ISO/IEC 14882 C++ Programming Language - ISO/IEC 11179 Metadata Registries, multiple parts - ISO/IEC 20943 MDR Content - ISO/IEC 20944 Metadata Access Service 11. Liaison Activities Liaison relationships should be maintained with the following standards committees: - JTC1/SC2 coded character sets - JTC1/SC6, RMODP and IDL - JTC1/SC22 programming languages - JTC1/SC22/WG20 internationalization - JTC1/SC25/WG4, maintenance of IEC 60559 (IEEE floating point) - JTC1/SC32 data management and interchange - JTC1/SC34 document description and processing languages - TC184/SC4 product data - TC211 geographic information systems - IEEE 1596.5, scalable coherent interface (datatypes and representations) Liaision relationships should be maintained with the following specification committees: - W3C - OMG - IETF ---------------------------------------------------------------------- _______________________________________________________________________ Frank Farance, Farance Inc. T: +1 212 486 4700 F: +1 212 759 1605 mailto:frank@farance.com http://farance.com Standards, products, services for the Global Information Infrastructure