ISO/IEC JTC 1 Information Technology
ISO/IEC JTC 1 N 5182
DATE: 1998.02.19
REPLACES
DOC TYPE: Other document (Open)
TITLE: Transmittal of IT Ad Hoc Recommendation Regarding JTC 1 N 3889 - Collaborative Computing and Standards Development
SOURCE: JTC 1 Ad Hoc Group on Strategy for Implementing Information Technology
PROJECT:
STATUS: As per the IT Ad Hoc Recommendation 9, document JTC 1 N 3889 is forwarded to the TMB AWG-IT for information. The IT Ad Hoc notes that although the document was prepared in 1996, the basic requirements contained therein are considered still valid. JTC 1 looks forward to working with the AWG-IT in exploring opportunities and capabilities for collaborative computing.
ACTION ID: FYI
DUE DATE:
DISTRIBUTION: P and L Members MEDIUM:
DISKETTE NO.:
NO. OF PAGES: 5
Secretariat, ISO/IEC JTC 1, American National Standards Institute, 11 West 42nd Street, New York, NY 10036; Telephone: 1 212 642 4932; Facsimile: 1 212 398 0023; Email: lrajchel@ansi.org
COLLABORATIVE COMPUTING AND STANDARDS DEVELOPMENT
INTRODUCTION
This paper examines the requirements for and characteristics of future collaborative computing approaches to the development and deployment of standards and related materials. Standards development today faces serious challenges. Participation in standards development is gradually eroding, due to the costs of
such participation and the doubt of the relevance of the process brought on by lack of timeliness in a rapidly-changing world. Organizations which themselves develop, market, or employ electronic technologies, and participate in the standards development process, increasingly feel that those technologies
must be used for, not just defined by, the standards process. Not to do so calls into question the very relevance and significance of international standards, not just the timeliness and relevance of the development process itself. In this climate, standards development organizations must aggressively
explore ways to use new technologies to improve and speed up the development process even as they explore ways to ensure that standards, once developed, will be accepted and used.
The paper will discuss existing approaches, both traditional and electronic, and briefly consider the characteristics and limitations of them, primarily to expose the set of requirements which any effective approach towards standards development must satisfy. The requirements for a collaborative computing approach will then be examined in terms of general needs, technical needs, human needs, and finally the needs of the standards bodies themselves.
EXISTING APPROACHES TOWARDS STANDARDS DEVELOPMENT
Existing approaches to the development and ultimate deployment of standards and related material include:
Paper and personal meetings
Bulletin board systems
Conferencing systems
Electronic mail
Listservs and repeater sites
Telephone conferencing
Video conferencing
Paper distribution and in-person meetings have been the primary means of standards development and distribution for many years. The primary advantage of this approach is the general availability of paper production and copying, and the full interaction available through in-person meetings. The two major
disadvantages to this approach are the cost of participation, and the length of time required in standards development; the former leading to lack of participation, and the latter to lack of relevance of standards which take many years to develop and progress.
Bulletin board systems and conferencing systems (a good public example of these is Compuserve; a myriad of private bulletin board systems abound throughout the world) provided the first examples of collaborative work, where a chain of related messages or comments could be maintained and used to gradually develop a
document. Such systems were used in some cases by standards groups, and did contribute to more rapid progression of work. However, several disadvantages emerged. Private systems required direct dial access, often very expensive. Even the public systems such as Compuserve required separate software and access
from the normal tools available to individuals during their day to day work, necessitating access after hours, or specialized equipment. Finally, the actual editing and messaging tools were very primitive and strictly text-oriented.
As electronic mail across public internetworks became more and more pervasive, the use of e-mail in standards development became more common. While some bulletin board or conferencing systems were made publicly available on the internet via Telnet or similar direct access, e-mail-based communications were far more attractive because they could be engaged in by anyone with e-mail capability, whether or not they had general internet access. The use of Listservs and Repeater sites allowed a form of threaded conferencing by repeating any message sent to the repeater to all participants in the discussion, and this form of collaboration is probably the most common form of electronic standards development at the time of writing.
The advantage, in addition to speed of interaction, is the ability to participate in the process at one s work site and without any additional equipment, software, specialized access needs or additional costs. Additionally, enhancements to the mail protocols such as MIME allow the interchange of encoded and
binary data, such as complexly-formatted material for word processors, graphical images, and the like. However, this technology does not permit very advanced approaches to collaboration, such as document markup and versioning, any form of synchronous interaction, or reasonable management controls; nor does it address standards distribution in any way. A final point, although subtle, is that the psychological distance of writing notes about what is being worked on, to go to one’s collaborators, tends to still require occasional in-person meetings to maintain a level of human interaction.
Telephone conferencing and video conferencing have been used in isolated instances as adjuncts to other methodologies for standards development, generally in place of an in-person meeting, and usually as a response to deadlines. While these technologies provide some of the human interaction missing in strictly abstract communications such as e-mail, they are very limited in terms of information exchange and are also very expensive. As video conferencing becomes more prevalent in large corporations, the limitations of the approach are starting to become apparent, and it is now obvious that video conferencing by itself is only effective in isolated cases, and generally with substantial advance preparation of accompanying physical
documents. While voice or even video interaction across the public internetwork is becoming possible, thus reducing the inherent cost while also reducing the fidelity of the interaction, the basic limitations of strictly voice or video interaction remain unchanged.
GENERAL REQUIREMENTS FOR COLLABORATIVE COMPUTING
An examination of the advantages and disadvantages of the existing approaches as delineated above provide a basic set of general requirements for any future technology-based means of standards development. These requirements include:
- The methodology must enable a more rapid development process
- It must enable much wider participation in the process
- It must substantially reduce the costs of standard participation
- It must enable broader distribution and acceptance of the products of the processes (standards and related materials)
- It must be generally available world-wide
- It must permit and promote necessary types of interactions to permit the human participants to be confident in the validity of the results
- It must provide the necessary types of controls and administration to provide confidence in the quality and integrity of the process and results
- It must provide the management and administration properties necessary to enable and enforce the industry, national and international agreements and protocols which are the foundation of the standards processes
- It must satisfy the necessary legal, copyright, and trademark issues necessary to allow and enhance the
development process, while safeguarding the dissemination and distribution of standards once developed
- It must support and complement the mission, funding and authority of accredited standards bodies and standards development organizations in the development, acceptance, and dissemination of standards
TECHNICAL REQUIREMENTS
In the material which follows, it is assumed that access to work in progress, and ultimately to standards documents and supporting material, will be through public internetworking. While some of the requirements for standards development can be met via a bulletin board system or conferencing system running on a host computer accessed via direct telephone calls, or through direct telephone or video conferencing, these approaches do not provide a general enough solution to permit widespread, and especially international participation, in the electronic standards development process.
The technical requirements for collaborative computing can be divided into three general areas:
- Repository, management and administration
- Asynchronous services
- Synchronous services
Respository, Management and Administration
The repository, management, and administrative facilities are those required to establish and maintain a controlled environment containing the work in progress, standards documents and other
materials, and managing the types of access and modification permitted to same. It should be noted that the set of these requirements suggests that a central system, functioning as a host or server, will be required in all but the simplest of document development scenarios. Furthermore, the obligations of access, control and versioning, plus the dictates of the enabling standards agreements, suggest the desirability of managing these repository environments by the controlling industry, regional, national or international standards body. Among the requirements for this set of facilities are:
- Run on and function as a server or host on the public internetwork
- Interact with asynchronous and synchronous client software to permit appropriate access, modification, addition and emendation of data, including all capabilities attributed below to asynchronous and synchronous services
- Support the necessary versioning, audit trails, multiple copies, etc. associated with the maintenance of dynamic, evolving documents
- Provide for controlled, managed access to data, and use of client tools, including the administration of security and the authentication of individuals and clients
- Allow the central administration and management of a collection of work in progress, standards and related documents with a minimum of human and systems resources
- Support multiple client products through open, standards-based interfaces where possible (as opposed to constraining clients to a single product)
- Implement the broadest possible set of client application protocol interfaces
While the proposed scenario would permit a central host syste with all work being performed on the host, probably through direct access via telnet or a similar interface (a sort of greatly-enhanced bulletin board system), the properties associated with the asynchronous requirements set suggest a client/server implementation, to permit individual interaction on an asynchronous basis while detached from the host or server and indeed from the internetwork.
Asynchronous Services
For the purposes of this document, asynchronous is defined as interaction where an individual may display, review, annotate and revise documents at any time convenient to him or her, with the subsequent collection, annotation and synchronization of material managed via some central fashion. The requirements for asynchronous services include:
- Original material capture, translation, annotation and posting to the repository, either as primary documents or as ancillary material
- Document review, modification and update facilities,
including
. Support for complex documents, including platform-
independent formatting and display, and supporting
publication-level formatting, graphics, and other forms
of embedded data and objects such as audio and motion
video
. Generalized edit functions appropriate to the data type
. Highlighting, paper clips , annotation and emendation
of text and all forms of data representation in
documents
. Imbedding, placement and property inheritance through
versioning
. Identification and audit trail of updates and updaters
- Discussion threads, including
. Multiple conversation threads linked to a specific
document, subject, or item
. Interleaving and cross-indexing between documents and
discussion threads
. Embedded links between discussion threads and document
updates, including versioning support and multiple
version display
- External linkage capabilities to allow a participant to
"cite" material elsewhere available on the network via
hyperlinks or repository-managed information capture and
replication
- Detached processing, implemented via data replication and
synchronization software or other technology to permit a
client to perform all participant asynchronous functions in
a network-detached mode, with subsequent re-attachment to
the network and automatic updating of common data,
documents, and other material
Synchronous Services
Synchronous services are those where a group of participants are all simultaneously online and sharing copies or views of the same material, and where comments or annotations made by any
person are automatically visible to all participants. In general, it should be noted that synchronous services will be value-add to the standards development process, in the sense that whereas the asynchronous and repository services are essential, these are complementary. It is also important to realize that, without the synchronous capabilities, in-person meetings will probably continue to be essential, whereas with these services, many in-person meetings may not be required. All of the functions required by repository services, and used by asynchronous services, will be needed by the synchronous services if actual data or document manipulation results. Finally, synchronous services can be used to support management and
organizational meetings where the actual development of standards documents is either not relevant, or constrained to relatively minor processes such as resolutions and positions statements. Requirements for synchronous services include:
- Whiteboard capability, including
. Simultaneous display of platform-formatted text,
graphics, and other data formats
. Simultaneous capture and redisplay of annotations to
displayed information
. Negotiated capture and preservation of accepted
modifications, updates and emendations to displayed
information, including restructuring into the
maintained form of the base data and documents
. Capture of all or selected annotations and
restructuring into repository-maintained discussion
threads related to documents and other materials,
maintaining order and participant identification
- Calendaring services
. Integrated to participants individual calendaring
systems as possible
. Structuring and posting of virtual and real meetings,
milestones, action plans and task lists
- Video/audio interaction capability, including
. Simultaneous display of whiteboard materials
. Audio-to-text capture and conversion to allow
discussion to be converted to either edits,
modifications, or discussion thread updates
. Capture of significant audio/visual segments and
preservation via repository services of these segments
as discussion thread updates
. Support of drafting committee work, entailing
interactive keyboard entry and display, modification,
acceptance and repository registration of document
HUMAN INTERACTION REQUIREMENTS
Regardless of what collaborative computing or other technology- based tools are provided to support the standards development process, these processes will succeed only insofar as they support and complete the natural requirements of human beings for interaction. In other words, if humans do not feel that the process they employ gives completeness or sufficient interactiveness, however these are defined, then the processes
will be deemed insufficient or incomplete. Conversely, processes which more than fulfill their purposes tend to satisfy other purposes and thus, without intent, promulgate more significant or severe corporate or social change than was originally intended. (Electronic mail is an example of both extremes: it has not been
sufficient to replace some human interactions predicted by industry pundits, yet it has been the cause of enormous corporaten change by enabling structural leveling, and thus been the harbinger of corporate reengineering, even though that was not the original intent of the implementors.
Our awareness of the human needs in interaction leads us to attribute a disproportionate level of validity towards capabilities such as video interaction. As a matter of record, those actual IT applications where video interaction was implemented have largely found that it was unnecessary once available, even though providing the capability was a necessity in gaining original acceptance of the application or service. It
is quite possible that standards development organizations will feel very strongly that synchronous interactions are absolutely essential, only to find that, once available, they are no longer necessary or even actually desirable, due to other pressures such as multiple time zones for participants in the process. While
this would suggest that synchronous interaction is not in fact a requirement, it really means only that interactive audio or video support may be more of a placebo than a true requirement. At the same time, these capabilities are the most human of the interaction technologies proposed, and may be key to acceptance even if their ultimate necessity might be argued.
STANDARDS BODIES REQUIREMENTS
These requirements fall into two realms: the requirements of administering the development of standards, and the requirements of promulgating the eventual standards once accepted. Thus these requirements are mostly related to the regulation, authorization and authentication of individuals participating in the standards development process; the collection of dues for such participation; and the eventual promulgation and distribution of the accepted standards, with revenues related to the purchase of same. While these needs are largely detached from the requirements associated with the development process, which argue
for relatively easy, inexpensive and painless participation, the proper role of the standards management organizations in implementing and managing the standards development process towards international acceptance is very real. Readily available, inexpensive participation in the standards development process actually promotes these needs, in that the revenues to support these organizations are derived in part from
participation dues. If it becomes radically easier and less expensive to participate, we may anticipate that many more entities will find that the dues were by far the least component of the costs, and increased dues revenue (good for the management body) and participation (good for the development process) should
result.
The other component, that of the promulgation and distribution of accepted standards, is outside the scope of this document. However, it seems likely that, even if completed and accepted standards are made available through some set of servers on the public internet, there will still be substantial markets for the
actual documents, although this market may be more for CD-ROM or equivalent technologies which support compound documents. The very limitation of online capability to the person conducting the
online process would suggest that the ability to acquire one's own, or one's company's own, copy of a standard will remain of significant value.