Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/reports/1989.08.fips

Text File | 1989-09-07 | 35KB | 794 lines

echo fips.adopt
cat >fips.adopt <<'shar.fips.adopt.13785'
From news  Thu Aug 17 21:29:56 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17290; Thu, 17 Aug 89 21:29:56 -0400
From: Vern Staats <[e-mail]>
Newsgroups: comp.std.unix
Subject: Should NIST adopt the Xt Intrinsics?  (long)
Keywords: xt intrinsics NIST NBS FIPS
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Vern Staats)
Date: 17 Aug 89 18:41:31 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Vern Staats)

I see that NIST is planning to adopt the X wire protocol, Xlib, and the
Xt Intrinsics as a FIPS PUB, for "network-based bit-mapped graphic system
applications acquired or internally developed for Federal use, which have
applications portability as a concern."  That's not a direct quote, but
it's pretty close.

Please note that the focus is on applications portability.  They specifically
state that this FIPS is not intended to specify a government-wide style or
"look & feel".

If adopted, most applications which fall into the above category would have
to be based on Xlib and the Xt Intrinsics.  While this initially struck me
as a good thing, I do have some questions about including the intrinsics.
Any answers/feedback/opinions would be greatly appreciated.

1)  They are specifying X11R3.  Shouldn't they really spec R4?

2)  Do the benefits of standardization outweigh losing Andrew, Interviews,
    (and others, I'm sure) applications which are not based on the intrinsics?

3)  It seems to me that for true application portability, you would need to
    either stay with Xlib, or standardize all the way up to the widget level.
    Creating a standard foundation for widget sets is all well and good, but
    the application may not be portable if you don't have the right widgets.
    Perhaps they should state that applications not be based on proprietary
    widget sets.

4)  Is ICCCM compliance important to application portability?

5)  There seem to be a few differences between the X Consortium intrinsics
    and those provided by DEC.  I assume other vendors have "enhanced" their
    intrinsics as well to provide extensions, better performance, etc.  The
    departures from the Consortium's intrinsics do not appear to have had
    much impact on applications portability; I can't recall seeing any
    questions on comp.windows.x regarding problems arising from differing
    intrinsics.  Am I correct in assuming that most vendors will have little
    difficulty producing compliant applications, even if they normally use
    extended intrinsics?

6)  I've heard that the X Consortium and X/Open are both opposed to
    standardizing on the intrinsics at R3 and even at R4.  Is this true?

Thanks again for any info.
If I get mail with points not covered on the net I'll post a summary.

NIST = National Institute of Standards and Technology,
       previously the National Bureau of Standards.
FIPS PUB = Federal Information Processing Standards Publication.

See Also:  Federal Register / Vol. 54, No. 108 / June 7, 1989, page 24372
and:  Mr. D. Richard Kuhn, NIST, Gaithersburg MD 20899, [phone].
NIST is soliciting comments until 5 September 1989.

----
      "Hundreds of miles apart, the ships inerted and their pilots
      fought with supreme skill to make the two intrinsics match."
      --  Edward E. Smith, Ph.D.
----

INET:  [e-mail]   Vern Staats  [phone]        /// Save
UUCP:  nap1!asd!staatsvr           ASD/SCED                       \\\/// The
Opinions:  my!own!                 WPAFB OH 45433                  \XX/ Guru

Volume-Number: Volume 17, Number 3

shar.fips.adopt.13785
echo fips.adopt.a
cat >fips.adopt.a <<'shar.fips.adopt.a.13785'
From news  Tue Aug 22 11:55:11 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA22379; Tue, 22 Aug 89 11:55:11 -0400
From: (Kuhn <[e-mail]>
Newsgroups: comp.std.unix
Subject: X FIPS
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Kuhn <[e-mail]>
Organization: National Institute of Standards and Technology
Formerly: National Bureau of Standards
Sub-Organization: National Computer and Telecommunications Laboratory
Date: 21 Aug 89 16:12:21 GMT
Apparently-To: std-unix-archive

From: Kuhn <[e-mail]>

Vern Staats posted some questions concerning the proposed NIST FIPS on the
X Window System.  I know that others have the same concerns.  We at
NIST tried to take these concerns into account in preparing the FIPS
proposal.  I'd like to respond to  the questions on behalf of NIST.

Rick Kuhn
Technology Bldg.  B266
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Gaithersburg, Md.  20899

301/975-3337

DDN:    [e-mail]
        [e-mail]
UUCP:    attunix!swe!kuhn


> From: [e-mail] (Vern Staats)
>
> I see that NIST is planning to adopt the X wire protocol, Xlib, and the
> Xt intrinsics as a FIPS PUB, for "network-based bit-mapped graphic system
> applications acquired or internally developed for Federal use, which have
> applications portability as a concern."  That's not a direct quote, but
> it's pretty close.
>
> Please note that the focus is on applications portability.  They specifically
> state that this FIPS is not intended to specify a government-wide style or
> "look & feel".
>
> If adopted, most applications which fall into the above category would have
> to be based on Xlib and the Xt intrinsics.  While this initially struck me
> as a good thing, I do have some questions about including the intrinsics.
> Any answers/feedback/opinions would be greatly appreciated.
>
> 1)  They are specifying X11R3.  Shouldn't they really spec R4?

Yes, but at the time the proposed FIPS was prepared, R3 was the current
release.  R4 should be the official X Consortium standard by the end of this
year.  The FIPS approval process will probably take until the end of the year
as well, so we can substitute R4 before the FIPS becomes official.
Furthermore,  NIST would like to keep the FIPS consistent with X Consortium
specs in the future.


> 2)  Do the benefits of standardization outweigh losing Andrew, Interviews,
>     (and others, I'm sure) applications which are not based on the intrinsics?
As with all NIST standards, if this FIPS does not meet the needs of an
agency, the agency is free to choose other technology.  So non X-based
solutions would not be lost to developers who need them.


> 3)  It seems to me that for true application portability, you would need to
>     either stay with Xlib, or standardize all the way up to the widget level.
>     Creating a standard foundation for widget sets is all well and good, but
>     the application may not be portable if you don't have the right widgets.
>     Perhaps they should state that applications not be based on proprietary
>     widget sets.

Currently there are no widget standards, from the X Consortium or anyone
else.  IEEE P1201 is working toward a standard for an X based toolkit, and
NIST is participating in this effort.  In fact, P1201 will base its work on
the FIPS.

> 4)  Is ICCCM compliance important to application portability?

Yes, NIST will consider inclusion of ICCCM in an update of the FIPS.


> 5)  There seem to be a few differences between the X Consortium intrinsics
>     and those provided by DEC.  I assume other vendors have "enhanced" their
>     intrinsics as well to provide extensions, better performance, etc.  The
>     departures from the Consortium's intrinsics do not appear to have had
>     much impact on applications portability; I can't recall seeing any
>     questions on comp.windows.x regarding problems arising from differing
>     intrinsics.  Am I correct in assuming that most vendors will have little
>     difficulty producing compliant applications, even if they normally use
>     extended intrinsics?

All vendors have extended the Intrinsics.  One of the reasons for the
development of R4 and R4+ is to make the Intrinsics more complete as a
basis for toolkit development.   NIST intends to update the FIPS to the
X Consortium specs as they are completed.  Vendors who follow the X
Consortium standards will be updating their applications as well.  The X
Consortium is committed to making the next version of the Intrinsics source
code compatible with R3.


> 6)  I've heard that the X Consortium and X/Open are both opposed to
>     standardizing on the Intrinsics at R3 and even at R4.  Is this true?

No, it isn't, with respect to the Federal government standardizing on R3
intrinsics.  Bob Scheifler, director of the X Consortium, has expressed
his support for adoption of R3 as a FIPS.  X/Open has taken no position on
the adoption of R3 as a FIPS.


Volume-Number: Volume 17, Number 4

shar.fips.adopt.a.13785
echo fips.text
cat >fips.text <<'shar.fips.text.13785'
From news  Thu Aug 31 08:29:28 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA08122; Thu, 31 Aug 89 08:29:28 -0400
From: Rick Kuhn <[e-mail]>
Newsgroups: comp.std.unix
Subject: X FIPS Text
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Rick Kuhn <[e-mail]>
Organization: National Institute of Standards and Technology
Formerly: National Bureau of Standards
Sub-Organization: National Computer and Telecommunications Laboratory
Date: 30 Aug 89 13:53:52 GMT
Apparently-To: std-unix-archive

From: Rick Kuhn <[e-mail]>

This is the text of NIST's proposed Federal Information Processing Standard
based on X.  There's a lot of official boilerplate and legalese here, but
the FIPS can be summarized very easily:  it adopts the X Consortium
specifications for X11 release 3 for X protocol, Xlib, Xt, and bitmap
distribution format as a Federal Information Processing Standard.  NIST based
it on release 3 to get the process going; we intend to substitute release 4
before the FIPS becomes official.  I've also included some questions and my
answers that appeared on xpert and std-unix.  These should be helpful
since I know that many people aren't familiar with the standards process
and NIST's role in that process.

Please contact me if you have any questions on the meaning or requirements
of the FIPS.  Official responses should be sent to the director of
NCSL/NIST at the address given in the FIPS, not to me.


Rick Kuhn
Technology Bldg.  B266
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Gaithersburg, Md.  20899

301/975-3337

DDN:    [e-mail]
UUCP:    attunix!swe!kuhn

-------------------------------------------------------------------------------
                   FEDERAL INFORMATION
            PROCESSING STANDARDS PUBLICATION


              Announcing the Standard for

            The User Interface Component of the

               Applications Portability Profile

Federal Information Processing Standards Publications (FIPS PUBS)
are issued by the National Institute of Standards and Technology
after approval by the Secretary of Commerce pursuant to Section
111(d) of the Federal Property and Administrative Services Act of
1949 as amended by the Computer Security Act of 1987, Public Law
100-235.

Name of Standard.  The User Interface Component of the
Applications Portability Profile.

Category of Standard.  Software Standard, Application Program
Interface.

Explanation.  This publication announces the adoption of the X
Protocol, Xlib Interface, Xt Intrinsics and Bitmap Distribution
Format specifications of the X Window System, Version 11, Release
3 (X Window System is a trademark of the Massachusetts Institute
of Technology (MIT)) as a Federal Information Processing
Standard. This standard is for use by computing professionals
involved in system and application software development and
implementation.  This standard is part of a series of
specifications needed for application portability.  The Appendix
to this standard contains a reference model for network-based
bit-mapped graphic user interface standards.  This standard
covers the Data Stream Encoding, Data Stream Interface, and
Subroutine Foundation layers of the reference model.  It is the
intention of NIST to provide standards for other layers of the
reference model as consensus develops within industry.  This
standard addresses the user interface functional area of the
Applications Portability Profile that was announced in FIPS 151,
POSIX: Portable Operating System Interface for Computer
Environments.

Approving Authority.  Secretary of Commerce.

Maintenance Agency.   U.S. Department of Commerce, National
Institute of Standards and Technology (NIST), National Computer
Systems Laboratory.

Cross Index.  The X Window System, Version 11, Release 3.

Related Documents.
    a. Federal Information Resources Management Regulation
201-8.1,Federal ADP and Telecommunications Standards.
    b. Draft Proposed American National Standard X3J11/87-
140,"Programming Language C".
     c. FIPS 151, POSIX:  Portable Operating System Interface for
Computer Environments.

Objectives.   This FIPS permits Federal departments and agencies
to exercise more effective control over the production,
management, and use of the Government's information resources.
The primary objectives of this FIPS are:
    a. To promote portability of computer application programs
at the source code level.
    b. To simplify computer program documentation by the use of
a standard portable system interface design.
    c. To reduce staff hours in porting computer programs to
different vendor systems and architectures.
    d. To increase portability of acquired skills, resulting in
reduced personnel training costs.
    e. To maximize the return on investment in generating or
purchasing computer programs by insuring operating system
compatibility.
    f. To provide ease of use in computer systems through
network-based bit-mapped graphic user interfaces with a
consistent appearance. Government-wide attainment of the above
objectives depends upon the widespread availability and use of
comprehensive and precise standard specifications.

Applicability.  This FIPS shall be used for network-based bit-
mapped graphic systems that are either developed or acquired for
government use where distributed/networked bit-mapped graphic
interfaces to multi-user computer systems are required.


Specifications.  The specifications for this FIPS are the
following documents from the X Window System, Version 11, Release
3.  These specifications define a C language source code level
interface to a network-based bit-mapped graphic system.  The
computer program source code contained in Version 11, Release 3
is not part of the specifications for this FIPS.  The
specifications for this FIPS are the following documents from X
Version 11, Release 3:
    a. X Window System Protocol, X Version 11,
    b. Xlib - C language X Interface,
    c. X Toolkit Intrinsics - C Language Interface,
    d. Bitmap Distribution Format 2.1.

Implementation.  This standard is effective (6 months after date
of publication in the Federal Register).  The other elements
identified in the Appendix should be considered in planning for
future procurements.

    a.  Acquisition of a Conforming System.  Organizations
developing network-based bit-mapped graphic system applications
which are to be acquired for Federal use after the effective date
of this standard and which have applications portability as a
requirement should consider the use of this FIPS.  Conformance to
this FIPS should be considered whether the network-based bit-
mapped graphic system applications are:
        1. developed internally,
        2. acquired as part of an ADP system procurement,
        3. acquired by separate procurement,
        4. used under an ADP leasing arrangement, or
        5. specified for use in contracts for programming
services.

    b.  Interpretation of the FIPS for the User Interface
Component of the Applications Portability Profile.    NIST
provides for the resolution of questions regarding the FIPS
specifications and requirements, and issues official
interpretations as needed.  All questions about the
interpretation of this FIPS should be addressed to:
    Director
National Computer Systems Laboratory
Attn: APP User Interface Component FIPS
Interpretation
National Institute of Standards and Technology
Gaithersburg, MD 20899


    c.  Validation of Conforming Systems.    The X Testing
Consortium has developed a validation suite for measuring
conformance to this standard.  NIST is considering the use of the
X Testing Consortium validation suite as the basis for an NIST
validation suite for measuring conformance to this standard.

Waivers.  Under certain exceptional circumstances, the heads of
Federal departments and agencies may approve waivers to Federal
Information Processing Standards (FIPS).  The head of such
agency may redelegate such authority only to a senior official
designated pursuant to section 3506(b) of Title 44, U.S. Code.
Waivers shall be granted only when:
    a.  Compliance with a standard would adversely affect the
accomplishment of the mission of an operator of a Federal
computer system, or
    b.  Cause a major adverse financial impact on the operator
which is not offset by Government wide savings.

Agency heads may act upon a written waiver request containing the
information detailed above.  Agency heads may also act without a
written waiver request when they determine that conditions for
meeting the standard cannot be met.  Agency heads may approve
waivers only by a written decision which explains the basis on
which the agency head made the required finding(s).  A copy of
each such decision, with procurement sensitive or classified
portions clearly identified, shall be sent to:  National
Institute of Standards and Technology; ATTN:  FIPS Waiver
Decisions, Technology Building, Room B-154; Gaithersburg, MD
20899.

In addition, notice of each waiver granted and each delegation
of authority to approve waivers shall be sent promptly to the
Committee on Government Operations of the House of
Representatives and the Committee on Governmental Affairs of the
Senate and shall be published promptly in the Federal Register.

When the determination on a waiver applies to the procurement of
equipment and/or services, a notice of the waiver determination
must be published in the Commerce Business Daily as a part of the
notice of solicitation for offers of an acquisition or, if the
waiver determination is made after that notice is published, by
amendment to such notice.

A copy of the waiver, any supporting documents, the document
approving the waiver and any supporting and accompanying
documents, with such deletions as the agency is authorized and
decides to make under 5 U.S.C. Sec. 552(b), shall be part of the
procurement documentation and retained by the agency.

Where to Obtain Copies:  Copies of this publication are for sale
by the National Technical Information Service, U.S. Department of
Commerce, Springfield, VA 22161.  (Sale of the included
specifications document is by arrangement with the Massachusetts
Institute of Technology and Digital Equipment Corporation.)  When
ordering, refer to Federal Information Processing Standards
Publication ____ (FIPSPUB____), and title.  Payment may be made
by check, money order, or deposit account.



APPENDIX

The FIPS for User Interface is part of a series of FIPS for the
Applications Portability Profile (APP), first announced in FIPS
151 (POSIX).  The functional components of the APP constitute a
"toolbox" of standard elements that can be used to develop and
maintain portable applications.  The APP is an open systems
architecture based upon non-proprietary standards.

One of the most neglected aspects of applications software
portability is the requirement to maintain a consistent user
interface across all systems on which the application resides.
The FIPS for User Interface is the first step in responding to a
critical need within the Federal community for a set of tools to
develop standard user interfaces.  It is the first in a series
which we intend to adopt as user interface technology progresses
and consensus emerges.

This initial FIPS is based upon the X Window System developed by
the Massachusetts Institute of Technology (MIT) X Consortium.
The X Window System assumes a client/server model of distributed
computing, and user interface applications based upon bit-mapped
graphic displays.  With this system, software vendors can develop
applications that incorporate such interfaces without being
concerned about the underlying display hardware on which the
application runs.  In addition, the application need not be
resident on the same computer system as the one to which the
user's display is attached.

This FIPS is not intended to specify a government-wide style or
"look and feel", nor is it intended as a specification of a
general programming interface for graphics applications.  It is
intended to lay a foundation for standards that will help Federal
agencies develop and acquire network-based, bit-mapped graphic
user interface applications.

The X Window System program services and interface specifications
adopted by this FIPS provide the foundation for a set of vendor
independent building blocks that can be used to develop user
interface applications.  These specifications, however, must be
extended to provide the additional program services and interface
specifications for user interface applications.  These additional
specifications will be based on the NIST User Interface reference
model shown in Figure 1.

The NIST User Interface reference model is a layered model which
defines the program services and interfaces required for
network-based, bit-mapped graphic user interface applications.
This FIPS covers the Data Stream Encoding, Data Stream Interface,
and Subroutine Foundation layers of the framework.  These layers
provide a foundation upon which standard components for higher
layers of the framework may be built. NIST User Interface Reference Model


  Model Layer                                System Component
-----------------------------------------------------------------
6:  Application                              | Application
-------------------------------------------|
5:  Dialogue             |                 | UIL, UIMS
--------------------------                 |
4:  Presentation         |                 | UIL, UIMS
--------------------------------           |
3:  Toolkit                    |           | Toolkit
--------------------------------------     |
2:  Subroutine Foundation            |     | Xt Intrinsics
-------------------------------------------|
1:  Data Stream Interface                  | Xlib
-------------------------------------------|
0:  Data Stream Encoding                   | X Protocol
-----------------------------------------------------------------


                        FIGURE 1.




Layer 0:  Data Stream Encoding

Data Stream Encoding defines the format and sequencing of byte
streams passed between client and server.  In the X Window
System, the Data Stream Encoding is the X "wire" or "network"
protocol.  As a specification of message formats, the Data Stream
Encoding is independent of operating system, programming
language, or network communication.


Layer 1:  Data Stream Interface

The Data Stream Interface specifies a function call interface to
build the messages defined in the Data Stream Encoding layer.  In
X, this interface is the Xlib function library. The Data Stream
Interface converts parameters passed from a program into the bit
stream that is transmitted over the network, and converts
messages from the server into values passed to the program. The
Data Stream Interface provides access to basic graphic functions
from Layer 0, and may support system functions such as error
handling and syncronization.






Layer 2:  Subroutine Foundation

The Subroutine Foundation uses features of the Data Stream
Interface to provide the means to build components of window
interfaces such as scroll bars.  Functions often provided by the
Subroutine Foundation include initializationa and destruction of
objects, management of events and object hierarchy, and the
saving and restoration of interface state.  The Subroutine
Foundation can be thought of as a toolkit with which to build
toolkits. The X Window System's Xt Intrinsics set is a Subroutine
Foundation for X.


Layer 3:  Toolkit

Components such as menus, pushbuttons, scroll bars, or help boxes
can be used to build an application interface.  These
"prefabricated" components make up the Toolkit.  The components
of Toolkits vary with vendors, but they typically contain most of
the common user interface elements.


Layer 4:  Presentation

The Presentation layer determines the appearance of the user
interface, including aspects such as size, style, and color.  It
specifies how the components in the Toolkit should be composed to
create windows.  The appearance may be specified using a User
Interface Language (UIL) and may be enforced by a window manager,
which controls the size and location of windows, and decorates
windows in the style specified by the user.  For example, an
application program will provide text for a title bar, but the
window manager determines the appearance of the title bar.

Layer 5:  Dialogue

The Dialogue layer coordinates the interaction between the
computer system and the user. It can be thought of as a mediator
between the user and the application program.   Communication
between user and application program is through the Dialogue
layer, which may be implemented by a User Interface Management
System (UIMS).  The user/application interaction is specified by
a "dialogue" that associates user actions, such as clicking on a
menu item, with application actions.  Some UIMS tools can accept
a dialogue and a presentation style from which to generate an
instance of the UIMS that controls the interaction between user
and application.





Layer 6:  Application

The application program implements the functions required by the
user.  Its interaction with the user is through the Dialogue
layer.




PLANS

The FIPS for User Interface is an integral component of the APP.
As with other components of the APP, the specifications adopted
by this FIPS are expected to evolve as the technology matures, as
additional experience using the technology is gained, and as
consensus broadens in the national and international standards
arena.  NIST has established a process to ensure that the FIPS
will evolve in a manner that serves the interests of both users
who employ these specifications to acquire products and vendors
who use them to build products.

Both users and vendors are included in this process through an
ongoing series of APP User Workshops and APP Implementor
Workshops.  The user workshops provide information on the
evolving definition of the User Interface Component as well as
other APP specifications.  They also serve as a forum for users
to identify user priorities and to provide input and feedback.
The implementor workshops provide a forum for vendors to discuss
the APP specifications and to provide feedback on the technical
merits of the NIST proposals.  The implementor workshops are
designed to ensure that there is consensus on the part of the
vendors to building products to the evolving APP specifications.


[1] Scheifler, R.W., and J. Gettys, "The X Window System,"  ACM
Transactions on Graphics, Vol. 5, No. 2, April, 1986.


===============================================================================

These are some questions about the FIPS that appeared on the xpert and
unix-stds mailing lists.

-------------------------------------------------------------------------------

Vern Staats posted some questions concerning the proposed NIST FIPS on the
X Window System.  I know that others have the same concerns.  We at
NIST tried to take these concerns into account in preparing the FIPS
proposal.  I'd like to respond to  the questions on behalf of NIST.

Rick Kuhn
Technology Bldg.  B266
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Gaithersburg, Md.  20899

301/975-3337

DDN:    [e-mail]
        [e-mail]
UUCP:    attunix!swe!kuhn


> From: [e-mail] (Vern Staats)
>
> I see that NIST is planning to adopt the X wire protocol, Xlib, and the
> Xt intrinsics as a FIPS PUB, for "network-based bit-mapped graphic system
> applications acquired or internally developed for Federal use, which have
> applications portability as a concern."  That's not a direct quote, but
> it's pretty close.
>
> Please note that the focus is on applications portability.  They specifically
> state that this FIPS is not intended to specify a government-wide style or
> "look & feel".
>
> If adopted, most applications which fall into the above category would have
> to be based on Xlib and the Xt intrinsics.  While this initially struck me
> as a good thing, I do have some questions about including the intrinsics.
> Any answers/feedback/opinions would be greatly appreciated.
>
> 1)  They are specifying X11R3.  Shouldn't they really spec R4?

Yes, but at the time the proposed FIPS was prepared, R3 was the current
release.  R4 should be the official X Consortium standard by the end of this
year.  The FIPS approval process will probably take until the end of the year
as well, so we can substitute R4 before the FIPS becomes official.
Furthermore,  NIST would like to keep the FIPS consistent with X Consortium
specs in the future.


> 2)  Do the benefits of standardization outweigh losing Andrew, Interviews,
>     (and others, I'm sure) applications which are not based on the intrinsics?
As with all NIST standards, if this FIPS does not meet the needs of an
agency, the agency is free to choose other technology.  So non X-based
solutions would not be lost to developers who need them.


> 3)  It seems to me that for true application portability, you would need to
>     either stay with Xlib, or standardize all the way up to the widget level.
>     Creating a standard foundation for widget sets is all well and good, but
>     the application may not be portable if you don't have the right widgets.
>     Perhaps they should state that applications not be based on proprietary
>     widget sets.

Currently there are no widget standards, from the X Consortium or anyone
else.  IEEE P1201 is working toward a standard for an X based toolkit, and
NIST is participating in this effort.  In fact, P1201 will base its work on
the FIPS.

> 4)  Is ICCCM compliance important to application portability?

Yes, NIST will consider inclusion of ICCCM in an update of the FIPS.


> 5)  There seem to be a few differences between the X Consortium intrinsics
>     and those provided by DEC.  I assume other vendors have "enhanced" their
>     intrinsics as well to provide extensions, better performance, etc.  The
>     departures from the Consortium's intrinsics do not appear to have had
>     much impact on applications portability; I can't recall seeing any
>     questions on comp.windows.x regarding problems arising from differing
>     intrinsics.  Am I correct in assuming that most vendors will have little
>     difficulty producing compliant applications, even if they normally use
>     extended intrinsics?

All vendors have extended the Intrinsics.  One of the reasons for the
development of R4 and R4+ is to make the Intrinsics more complete as a
basis for toolkit development.   NIST intends to update the FIPS to the
X Consortium specs as they are completed.  Vendors who follow the X
Consortium standards will be updating their applications as well.  The X
Consortium is committed to making the next version of the Intrinsics source
code compatible with R3.


> 6)  I've heard that the X Consortium and X/Open are both opposed to
>     standardizing on the Intrinsics at R3 and even at R4.  Is this true?

No, it isn't, with respect to the Federal government standardizing on R3
intrinsics.  Bob Scheifler, director of the X Consortium, has expressed
his support for adoption of R3 as a FIPS.  X/Open has taken no position on
the adoption of R3 as a FIPS.


-------------------------------------------------------------------------------



Correction of a typo in my previous posting:  In the answer to question 2,
please substitute "Xt" for "X":

>> 2)  Do the benefits of standardization outweigh losing Andrew, Interviews,
>>   (and others, I'm sure) applications which are not based on the intrinsics

>As with all NIST standards, if this FIPS does not meet the needs of an
>agency, the agency is free to choose other technology.  So non X-based
>solutions would not be lost to developers who need them.



I'd also like to add to the explanation of what is and is not required by the
FIPS.   It does not require agencies to write applications that call only
Xt and Xlib.  It does not prohibit vendors from supplying extensions.
At this time there is clearly a need to use both toolkit functions and
extensions in applications.  The intent of the FIPS is to promote application
portability at the source code level.  We can do this to some extent now by
establishing a common base.  It will be possible to a much greater extent
when IEEE P1201 completes its standard toolkit API.  At that point it will
be possible to develop many useful applications using only standard
interfaces, but even then some applications will require the use of
proprietary extensions or entirely non-standard systems.  This is
inevitable, and it would be silly to attempt to prohibit it.  Allowing the
use of extensions and non-standard systems, when necessary, also helps to
ensure that standards do not limit innovation.


Rick Kuhn

-------------------------------------------------------------------------------

Although this question was not on xpert, it comes up frequently:

> If an application includes a toolkit that is based on Xlib but not on Xt, is
> it compliant?


It is compliant if the source code is available.  The FIPS is intended
to provide applications portability, so if the source code for the toolkit
is available it can be ported along with the application to another system
that supports Xlib.  Note that this assumes that the toolkit is not
dependent on any proprietary extensions to Xlib or on proprietary operating
system functions.


Volume-Number: Volume 17, Number 13

shar.fips.text.13785
exit