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


JTC 1 N 3889 

 

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.