Object Management Group
Framingham Corporate Center
492 Old Connecticut Path
Framingham, MA  01701-4568
USA

email:info@omg.org     
http://www.omg.org
Tel: +1-508-820 4300
Fax: +1-508-820 4303

Common Facilities Task Force RFI5
For RFP7 Asian Input Facility

Submissions Due: October 16, 1996
OMG Document # cf/96-06-03

1. Introduction

This Request for Information (RFI) solicits information about requirements, projects, and products that will provide guidance for the International input facility related object system interoperability with an emphasis on Asian multi-byte languages. The Object Management Group (OMG) will use this information to begin the technology adoption process for OMG-compliant interfaces for input facility objects. The overall goal will be to adopt vendor-neutral common interfaces:

  To improve the quality of services and reduce costs by utilizing CORBA technologies for interoperability throughout the various language communities, especially those of Asian languages requiring multi-byte characters.
  To utilize the OMG technology adoption process to standardize interfaces of input facility objects for various international languages, including, but not limited to, Asian languages.
  To communicate the requirements of the various language communities to the Platform Technical Committee.
  To assist and advise the Liaison Subcommittee regarding the relationship with national standard organizations and consortia in the world.

The OMG encourages users, consultants, systems integrators, and developers of Asian character related devices, instruments, applications and systems to become involved with this process by responding to this RFI. OMG members and non-members may submit. Members representing non-Asian language communities are welcome for responding to this RFI and requesting expansion of  the scope of input facility beyond Asian languages to languages of their concern. Current compliance with OMG specifications is not a prerequisite for response to this RFI. The RFI response can consist of pre-existing product documentation, but should preferably be organized and presented in accordance with this RFI.
The Common Facility Task Force (CFTF) will use responses to this RFI to define one or more RFPs soliciting OMG IDL interfaces and corresponding semantic descriptions and sequencing constraints.

 Context and Scope

OMG's central mission is to establish an architecture and set of specifications to enable distributed integrated applications. Primary goals are the reusability, portability and interoperability of object-oriented software components in distributed heterogeneous computing environments. Much of OMG's
effort to date has been focused on establishing an enabling infrastructure based on open and standard interface definitions. More recently the OMG has started the process of standardizing common interfaces in international contexts.

 Objectives

This RFI seeks information to help the CFTF make useful and efficient decisions in the input facility technology adoption process.

2. Information Being Requested

This RFI is seeking information in the categories described below. Respondents are asked only to address those areas for which they have expertise and/or interest. Please consider the purpose of this RFI when responding so your time is spent on issues that will be helpful to reviewers. Respondents may consider areas not explicitly asked here for if they feel the information provides useful guidance for the Common Facilities Task Force. 

2.a. User Requirements for Interoperability

We are specifically asking developers of input facility systems, modules, programs, and libraries to respond as to their requirements for interoperability between these entities. We are specifically looking for areas in which there is a strong need today or projected in the near future.

In addition, any language and platform specific issues that the Common Facility Task Force should be aware of as we go through the technology adoption process regarding the common interface for input facility objects.  These user requirements are very important in determining the urgency of technology adoption in specific areas.

2.b. Standards

There are many important sources of standards to consider when adopting technology specifications by a consortium.  This includes de facto industry standards as well as de jure standards developed by
recognized standards organizations in various settings. The input facility is highly depending upon language and character specific standards, especially those of character code sets and keyboard mappings. It is important to identify those standards that have a strong following as well as those areas that are suffering from a lack of standard mechanisms for interoperability between systems and between languages.
It is requested that respondents concentrate on important standards issues as well as significant comparisons as to the differences between standards. It can also be important to identify problems with current standards that prevent their acceptance or cause problems in their implementation.

Identification of standards groups that would provide beneficial liaison with the Object Management Group is one of objectives in this RFI.

2.c. Questions to Derive Architectural Framework 

Since there are so many different and diversified needs and views in the broad field of language/character-sets specific technology, there is a need to decompose and structure of input facilities so the manageable pieces can be discussed and prepared for technology adoption.  CFTF is in need of an architectural framework that can be used to lay out how to decompose the models of input facility. To start, it is indispensable to find out how input facility is modeled and used in a specific language, and to identify what can be shared as common among languages. 

The problems of input facilities are multidimensional.  The framework being sought could break this down in a number of ways, for example, with specific questions that may need to be addressed in designing an architectural framework:

	Hardware constraints vs. language/character specific needs
Many languages and characters, especially those of Asian countries, require more characters than a keyboard or any other input instrument can handle. In many languages, this problem is addressed with an input facility that maps key inputs to characters or code sets. Please elaborate what hardware constraints are prevailing in inputs of characters
	Languages and characters specific input schemes
Input facilities today provide various input schemes. For examples,  some input facilities require end-users input phonemes, some require character codes, and some require character parts. Are end-users’ inputs needed to be converted, for example, from phonemes to characters? What schemes of character inputs are prevailing? 
Application specific needs vs. Interoperability on a platform
How much interoperability among applications is achieved by input facilities, while application specific needs are also maintained?
	Dictionary needs
Does input facility (with conversions) require a dictionary? If yes, how is it used? Or, what is it composed of? Characters, words, or composite words?
	Conversion and user interface needs
What facility or user interface is provided for input conversion? Anything common as language independent? Or what needs to be language specific? 
	Input facility models vs. input facility specific utility needs
Does input facility object model have anything to do with input facility specific utility, such as dictionary maintenance?
	Languages and characters independence
How much of input facility can be common and shared across languages and characters as language / character independent?

It is possible for an architectural framework to consist of multiple levels of decomposition.  The lowest level would ideally represent specific RFPs that could be issued for technology adoption.

2.d. Interfaces

Responses may also identify specific objects, such as, but not limited to, dictionaries and user interface objects, that need interface standards in order to facilitate interoperability between input devices (not necessarily keyboards), dictionaries, applications, and systems.  This may include groups of such objects, in which case it may overlap with the information being requested under Architectural Framework.  These could be objects found in one particular language, its subset domain, a set of domains, or objects that are needed by all or most users in these particular domains.
Respondents should realize that all else being equal, objects representing the most significant needs by the broadest range of user communities would be the top priority of the Common Facility Task
Force.

If a respondent lists a significant number of objects or object groups it would be helpful for them to indicate their priorities for adoption through CFTF.

2.e. Existing Systems and Programs

This is an opportunity for CFTF to discover where technology is currently being applied to facilitate language and/or character-set specific input facilities.  A major goal is to identify the maturity of technology and development in specific areas.  This information will be used along with the user requirements to determine the appropriate road map for standardization efforts.  Those areas
with the highest benefit that have mature technology will be considered for adoption first. Respondents are requested to submit the list of systems, products, programs, or libraries that
provide input facility functions. If respondents specify on which  hardware and system platform technology is available, it would be helpful for CFTF to identify the relevancy of such technology to the OMG framework. 
If language and/or character specific input devices are developed for specific but widely used domains, such information upon input device is requested as well. This does not assume the input device is limited to keyboards but may include, for examples, voice / character
recognition systems.

3. Instructions for Responding to this RFI   

Companies responding to this RFI shall designate a single contact within that company for receipt of all subsequent information regarding this RFI and the forthcoming series of RFPs. The name
of this contact will be made available to all OMG members. 

Responses to this RFI must be received at OMG no later than 5:00PM, US Eastern Time (22:00 GMT) October 16, 1996. Documentation submitted in response to this RFI will be available to all OMG members.

3.a. Format of RFI Responses

The following outline is offered to assist in the development of your response. You should include:

A cover letter -- the cover letter should include a brief summary of your response such as indicating which areas you are responding to and indicate if supporting documentation is included in your response.

Your response to any or all of the areas information is requested by this RFI.
If necessary, please include a glossary which maps your terminology to OMG standard terminology. (See the Appendices to the OMA Guide and the CORBA Specification for OMG's standard
terminology.)

Although the OMG does not limit the size of responses, you are asked to consider that the OMG will rely upon volunteer resources with limited time availability to review these responses. In
order to assure that your response receives the attention it deserves, you are asked to consider limiting the size of your response (not counting any supporting documentation) to approximately 25 pages.

If you consider supporting documentation to be necessary, please indicate which portions of the supporting documentation are relevant to this RFI.

NOTE: According to the Policies and Procedures of the OMG Technical Committee, proprietary and confidential material may not be included in any response to the OMG. Responses become
public documents of the OMG. If copyrighted, a statement waiving that copyright for use by the OMG is required and a limited waiver of copyright that allows OMG members to make up to at
least twenty-five copies for review purposes is required.

 How to Submit

OMG requests that 50 paper copies of the response, one copy in IBM PC machine-readable format (typically ASCII, Word or WordPerfect format), and any supporting documentation to be sent to the Technology Desk at OMG.  Responses to this RFI (and other communication regarding this
RFI or related RFPs in the future) should be addressed to:

CFTF Technology Desk
Object Management Group Inc.
Framingham Corporate Center
492 Old Connecticut Path
Framingham, MA 01701-4568
USA

Phone: +1-508-820 4300
Fax: +1-508-820 4303
Email: cftf@omg.org

Responses to this RFI must be received at OMG no later than 5:00PM US Eastern Time (22:00 GMT) October 16, 1996.  The outside of packages/envelopes containing submissions or any other communication regarding this RFI should be clearly marked "CFTF  RFI RESPONSE".

NOTE: Your organization should be prepared to handle requests for additional copies of your response and should be prepared to handle requests for additional copies of supporting
documentation.

 Reimbursements

The OMG will not reimburse submitters for any costs in conjunction with their responses to this RFI.

4. Response Review Process and Schedule

Responses to this RFI are to be reviewed for the following express intention: providing OMG with technical information and guidance in writing the forthcoming series of RFPs.

Process

The OMG membership, specifically the Common Facility Task Force will review responses. Based on those responses, they will prepare one or more RFPs. These RFPs  will be presented to the entire OMG TC for acceptance. The accepted RFPs will be issued to the public.

As a forewarning to organizations who intend to respond to any RFP CFTF that may be issued, please note that responding to an RFP requires:

  A Letter of Intent (LOI) signed by an officer of your organization signifying your intent to respond to the RFP and a statement of your organization's willingness to comply with the OMG's requirements
(e.g., your willingness to license the proposed technology openly).

  The technology submission described in accordance to the RFP. Any technology adopted by the OMG must be commercially available from a Corporate Member. A statement describing how the submission meets this commercial availability requirement is required with the submission.

See the Schedule section below for a timetable listing the tentative dates when for the first RFP. Please consult the OMA Guide for a complete description of the OMG's requirements,
policies and procedures for technology submissions.

 Clarification of Responses

To fully comprehend the information contained within a response to this RFI, the reviewing group may seek further clarification on that response. This clarification may come in the form of
verbal communication over the telephone; written communication; electronic communication; or a request to make a presentation of the response.  CFTF requests that submitters attend the
meeting following the RFI deadline to present their responses.

 Schedule

The schedule for responding to this RFI is as follows. Please note that early responses are encouraged.
TF recommends issuing the RFI			 June 6, 1996
RFI issued					 June 6, 1996
RFI responses due				 October 16, 1996
The tentative schedule for the RFI evaluation process and subsequent RFPs is:
Review of RFI responses			November 6, 1996
TF recommends issuing the initial RFP		November 6, 1996
Initial RFP issued				November 7, 1996
NOTE: This schedule is subject to change based on the number of RFI responses received and the information acquired from the responses.

Appendix A: Background on the Object Management Group and the Common Facility Task Force

OMG is dedicated to producing a framework and specifications for commercially available object-oriented environments. The Object Management Architecture (OMA) Guide, published in 1990 (revised 1995), provides an architecture with terms and definitions upon which all supporting interface specifications are to be based. Part of this architecture is the Reference Model which identifies and characterizes the components, interfaces, and protocols that compose the OMA.

Figure 1 shows the four major parts of the OMA Reference Model. The circles and semi-circular figures represent software with application programming interfaces. The boxes represent groupings of objects that can make and receive requests.
• The Object Request Broker (ORB) enables objects to make and receive requests and responses.
• Object Services is a collection of services with object interfaces that provide basic functions for realizing and maintaining objects.
• Common Facilities is a collection of interfaces and objects that provide general purpose capabilities useful in many applications.
• Application Objects are specific to particular end-user applications.

Figure 1: OMA Reference Model

Through a series of RFPs, OMG is populating the OMA Reference Model with detailed specifications for each of its components and interfaces. The OMA's Object Model describes what an object is and what constructs are generally available for defining OMG objects. The Common Object Request Broker Architecture (CORBA) specification defines the OMG ORB - a mechanism which allows clients to issue requests to, and receive responses from conforming objects (Figure 2).

Figure 2: Common ORB Architecture

Using the ORB, requests for an object's services are made without regard to the location or implementation of the object providing the service, i.e., without regard for the mechanisms used to represent, store, manage, invoke or communicate with the object. Objects made available through the ORB publish their interfaces using the Interface Definition Language (OMG IDL) as defined in Chapter 4 of the CORBA specification. OMG IDL provides a language-independent way of specifying an object's operations and attributes.

To construct inter-working, portable clients and object implementations, there must exist a set of basic Object Services which provide functions for realizing and maintaining objects. Object Services provide the basic operations for logical modeling, naming, lifecycle, managing and physically storing objects. For example, Object Services define the operations used to create, find, move and delete objects, as well as the operations used to define an object and its implementations.
Tables 1 offers the list of the Common Facilities (CORBAfacilities). Table 2 shows the proposed roadmap for their adoptions.

User Interface Facilities Category
* Compound Presentation & Interchange
* Printing
* Asian Input
* Rendering Management
Information Management Facilities Category
* Data Interchange
* Meta-Object
* Information Storage and Retrieval
* Internationalization and Time Operations
System Management Facilities Category
* Common Management Facility
*Configuration and Change Management
*Security Administration
Task Management
* Mobile Agents
* Workflow
* Automation & Scripting
Table 1: Common Facilities (CORBAfacilities)

Cf RFP1 Compound Presentation and Interchange 		10/94 start - now complete
Cf RFP2 Internationalization and Time Operations 		3/95 start
Cf RFP3 Data Interchange and Mobile Agents 		11/95 start
Cf RFC1 Common Management Facility 			1/96 start
Cf RFP4 Business Objects 				1/96 start
 							(Note: this is being worked by the BODTF)
Cf RFP5 Meta-Object Facility 				6/96 planned/designated by  motion
Cf RFP6 Printing Facility 					3/96 start
 							(was issued at TC meeting - later this day)
Cf RFP7 Asian Input 					6/96 planned/designated by  motion
Cf RFP8 Automation & Scripting 				9/96 planned start
Cf RFC2 Workflow 					12/96 likely submission by WfMC
Cf RFP9 Rendering Management 				9/96 planned start
Cf RFP10 Information Storage and Retrieval 		3/97 planned start
Cf RFP11 Configuration & Change Management 		5/97 (ASAP after Meta-Object)
Cf RFP12 Rule Management 				8/97 planned start
Cf/ORBOS RFP Security Administration (tentative wrt/ security revision2) 
 							1/98 planned start
Table 2: Common Facilities (CORBAfacilities) Roadmap

For More Information:

More information on the Object Management Group can be obtained via the Internet at:

WWW Homepage 	http://www.omg.org/

OMG provides a document server.  Send e-mail to server@omg.org with a message body:

help
get docs/doclist.txt

References:

Object Management Architecture Guide  (OMA Guide),  Object Management Group, September 1995.
Common Object Request Broker Architecture and Specification  (CORBA), Revision 2, Object Management Group, August 1995.
CORBAservices,  Object Management Group, March  31, 1995, OMG TC Document 95-3-31.
CORBAsfacilities,  Object Management Group, to appear late 1995. (Interim OMG TC Doc# 95-1-2)
Mowbray, T.J. and R. Zahavi, The ESSENTIAL CORBA: Systems Integration Using Distributed Objects, John Wiley & Sons, New York, 1995. (ISBN 0-471-10611-9)

Appendix B: OMG Process

OMG adopts specifications for interfaces, based on existing technology, by explicit vote on a technology-by-technology basis. The specifications selected each fill in a portion of the OMA Reference Model. OMG bases its decisions on both business and technical merit. The OMG Technical Committee (TC) provides technical guidance to the OMG in making decisions about specifications. The TC is composed of representatives of all OMG member companies. The TC is operated by a Vice President of Technology, working full-time for the OMG itself (as opposed to being an employee of a member company).

The TC operates in a Request for Proposal mode, requesting technology to fill open portions of the Reference Model from international industry. The responses to such a proposal, taken within the specific RFP response period, are evaluated by a Task Force of the TC with the full TC then voting on a recommendation to the Board for approval of a specific addition to the set of OMA specifications. Once a specification (a technology, not source or product) has been adopted by the OMG Board, it is promulgated to the industry through a variety of distribution channels.

RFIs such as this one are issued with the intent to survey the industry to obtain information that provides guidance which will be used in the preparation of forthcoming RFPs.

The OMG's fast track process allows for faster adoption of technology in the case where an existing OMG compliant specification exists and there is likely to be no competition.