SQL:1999, formerly known as SQL3

Andrew Eisenberg Jim Melton

Sybase, Concord, MA 01742 Sandy, UT 84093
[email protected] [email protected]

number of Working Groups to actually do the

Background technical workWG3 (Database Languages) is
responsible for the SQL standard, while WG4 is
For several years now, youve been hearing and progressing the SQL/MM (SQL MultiMedia, a suite
reading about an emerging standard that everybody of standards that specify type libraries using SQLs
has been calling SQL3. Intended as a major object-oriented facilities).
enhancement of the current second generation SQL In the United States, IT standards are
standard, commonly called SQL-92 because of the handled by the American National Standards
year it was published, SQL3 was originally planned Institutes Accredited Standards Development
to be issued in about 1996but things didnt go as Committee NCITS (National Committee for
planned. Information Technology Standardization, formerly
As you may be aware, SQL3 has been known more simply as X3). NCITS Technical
characterized as object-oriented SQL and is the Committee H2 (formerly X3H2) is responsible for
foundation for several object-relational database several data management-related standards, including
management systems (including Oracles ORACLE8, SQL and SQL/MM.
Informix Universal Server, IBMs DB2 Universal When the first generation of SQL was
Database, and Cloudscapes Cloudscape, among developed (SQL-86 and its minor enhancement SQL-
others). This is widely viewed as a good thing, but 89), muchperhaps mostof the development work
it has had a downside, too: it took nearly 7 years to was done in the USA by X3H2 and other nations
develop, instead of the planned 3 or 4. participated largely in the mode of reviewing and
As we shall show, SQL:1999 is much more critiquing the work ANSI proposed. By the time
than merely SQL-92 plus object technology. It SQL-89 was published, the international community
involves additional features that we consider to fall was becoming very active in writing proposals for the
into SQLs relational heritage, as well as a total specification that became SQL-92; that has not
restructuring of the standards documents themselves changed while SQL:1999 was being developed, nor
with an eye towards more effective standards do we believe its likely to change in the future
progression in the future. SQL is truly an international collaborative effort.
A work of explanation is in order about the
Standards Development informal names were using for various editions of
the SQL standard. The first versions of the standard
Process are widely known as SQL-86 (or SQL-87, since the
The two de jure organizations actively involved in ISO version wasnt published until early 1987), SQL-
SQL standardization, and therefore in the 89, and SQL-92, while the version just now being
development of SQL:1999, are ANSI and ISO. finalized should become known as SQL:1999. Why
More specifically, the international the differencewhy not SQL-99? Well, simply
community works through ISO/IEC JTC1 (Joint because we have to start thinking about what the next
Technical Committee 1), a committee formed by the generation will be called, and SQL-02 seemed
International Organization for Standardization in more likely to be confused with SQL2 (which was
conjunction with the International Electrotechnical the project name under which SQL-92 was
Commission. JTC1s responsibility is to develop and developed)not to mention the fact that 02 isnt
maintain standards related to Information really greater than 99. In other words, we dont
Technology. Within JTC1, Subcommittee SC32, want even the name of the SQL standard to suffer
titled Data Management and Interchange, was from the year 2000 problem!
recently formed to take over standardization of
several standards related to database and metadata
that had been developed by other organizations (such Contents of SQL:1999
as the now-disbanded SC21). SC32, in turn, formed a With that background under our belts, its time to
take a survey of the actual contents of SQL:1999.
While we recognize that most readers of this column
will not know the precise contents of even SQL-92, WHERE COL1 > COL2 AND
space limitations prohibit our presenting the complete COL3 = COL4 OR
feature set of SQL:1999. Consequently, were going UNIQUE(COL6) IS NOT FALSE
to restrict our overview to just those features that are
new to this most recent generation of the SQL SQL:1999 also has two new composite
standard. types: ARRAY and ROW. The ARRAY type allows
The features of SQL:1999 can be crudely one to store collections of values directly in a column
partitioned into its relational features and its of a database table. For example:
object-oriented features. Well cover them in that
sequence for convenience. WEEKDAYS VARCHAR(10) ARRAY[7]

would allow one to store the names of all seven

Relational Features weekdays directly in a single row in the database.
Although we call this category of features Does this mean that SQL:1999 allows databases that
relational, youll quickly recognize that its more do not satisfy first normal form? Indeed, it does, in
appropriately categorized as features that relate to the sense that it allows repeating groups, which
SQLs traditional role and data modela somewhat first normal form prohibits. (However, some have
less pithy phrase. The features here are not strictly argued that SQL:1999s ARRAY type merely allows
limited to the relational model, but are also unrelated storage of information that can be decomposed, much
to object orientation. as the SUBSTRING function can decompose
These features are often divided into about character stringsand therefore doesnt truly violate
five groups: new data types, new predicates, the spirit of first normal form.)
enhanced semantics, additional security, and active The ROW type in SQL:1999 is an extension
database. Well look at each in turn. of the (anonymous) row type that SQL has always
had and depended on having. It gives database
New Data Types designers the additional power of storing structured
values in single columns of the database:
SQL:1999 has four new data types (although
one of them has some identifiable variants). The first CREATE TABLE employee (
of these types is the LARGE OBJECT, or LOB, type. EMP_ID INTEGER,
This is the type with variants: CHARACTER NAME ROW (
LARGE OBJECT (CLOB) and BINARY LARGE GIVEN VARCHAR(30),
OBJECT (BLOB). CLOBs behave a lot like character FAMILY VARCHAR(30) ),
strings, but have restrictions that disallow their use in ADDRESS ROW (
PRIMARY KEYs or UNIQUE predicates, in STREET VARCHAR(50),
FOREIGN KEYs, and in comparisons other than CITY VARCHAR(30),
purely equality or inequality tests. BLOBs have STATE CHAR(2) )
similar restrictions. (By implication, LOBs cannot be SALARY REAL )
used in GROUP BY or ORDER BY clauses, either.)
Applications would typically not transfer entire LOB SELECT E.NAME.FAMILY
values to and from the database (after initial storage, FROM employee E
that is), but would manipulate LOB values through a
special client-side type called a LOB locator. In While you might argue that this also violates first
SQL:1999, a locator is a unique binary value that acts normal form, most observers recognize it as just
as a sort of surrogate for a value held within the another decomposable data type.
database; locators can be used in operations (such as SQL:1999 adds yet another data type-related
SUBSTRING) without the overhead of transferring facility, called distinct types. Recognizing that its
an entire LOB value across the client-server generally unlikely that an application would want,
interface. say to directly compare an employees shoe size with
Another new data type is the BOOLEAN his or her IQ, the language allows programmers to
type, which allows SQL to directly record truth declare SHOE_SIZE and IQ to each be based on
values true, false, and unknown. Complex INTEGER, but prohibit direct mixing of those two
combinations of predicates can also be expressed in types in expressions. Thus, an expression like:
ways that are somewhat more user-friendly than the
usual sort of restructuring might make them: WHERE MY_SHOE_SIZE > MY_IQ
of UNIXs characters were already in use for other
(where the variable name implies its data type) would purposes in SQL.
be recognized as a syntax error. Each of those two The other new predicate, DISTINCT, is very
types may be represented as an INTEGER, but the similar in operation to SQLs ordinary UNIQUE
SQL system doesnt allow them to be mixed in predicate; the important difference is that two null
expressionsnor for either to be, say, multiplied by values are considered not equal to one another and
an INTEGER: would thus satisfy the UNIQUE predicate, but not all
applications want that to be the case. The DISTINCT
SET MY_IQ = MY_IQ * 2 predicate considers two null values to be not distinct
from one another (even though they are neither equal
Instead, programs have to explicitly express their to nor not equal to one another) and thus those two
deliberate intent when doing such mixing: null values would cause a DISTINCT predicate not to
be satisfied.
WHERE MY_SHOE_SIZE >
CAST (MY_IQ AS SHOE_SIZE)
SET MY_IQ =
SQL:1999s New Semantics
MY_IQ * CAST(2 AS IQ) Its difficult to know exactly where to draw the line
when talking about new semantics in SQL:1999, but
In addition to these types, SQL:1999 has well give a short list of what we believe to be the
also introduced user-defined types, but they fall into most important new behavioral aspects of the
the object-oriented feature list. language.
A long-standing demand of application
writers is the ability to update broader classes of
New Predicates views. Many environments use views heavily as a
SQL:1999 has three new predicates, one of which security mechanism and/or as a simplifier of an
well consider along with the object-oriented applications view of the database. However, if most
features. The other two are the SIMILAR predicate views are not updatable, then those applications often
and the DISTINCT predicate. have to escape from the view mechanism and rely
Since the first version of the SQL standard, on directly updating the underlying base tables; this
character string searching has been limited to very is a most unsatisfactory situation.
simple comparisons (like =, >, or <>) and the rather SQL:1999 has significantly increased the
rudimentary pattern matching capabilities of the range of views that can be updated directly, using
LIKE predicate: only the facilities provided in the standard. It depends
heavily on functional dependencies for determining
WHERE NAME LIKE '%SMIT_' what additional views can be updated, and how to
make changes to the underlying base table data to
which matches NAME values that have zero or more effect those updates.
characters preceding the four characters SMIT and Another widely-decried shortcoming of SQL
exactly one character after them (such as SMITH or has been its inability to perform recursion for
HAMMERSMITS). applications such as bill-of-material processing. Well,
Recognizing that applications often require SQL:1999 has provided a facility called recursive
more sophisticated capabilities that are still short of query to satisfy just this sort of requirement. Writing
full text operations, SQL:1999 has introduced the a recursive query involves writing the query
SIMILAR predicate that gives programs UNIX-like expression that you want to recurse and giving it a
regular expressions for use in pattern matching. For name, then using that name in an associated query
example: expression:

WHERE NAME SIMILAR TO WITH RECURSIVE

'(SQL-(86|89|92|99))|(SQL(1|2|3))' Q1 AS SELECT...FROM...WHERE...,
Q2 AS SELECT...FROM...WHERE...
(which would match the various names given to the SELECT...FROM Q1, Q2 WHERE...
SQL standard over the years). Its slightly
unfortunate that the syntax of the regular expressions Weve already mentioned locators as a
used in the SIMILAR predicate doesnt quite match client-side value that can represent a LOB value
the syntax of UNIXs regular expressions, but some stored on the server side. Locators can be used in the
same way to represent ARRAY values, accepting the
fact that (like LOBs) ARRAYs can often be too large keep a budget balanced by reducing monies set aside
to conveniently pass between an application and the for capital purchases whenever new employees are
database. Locators can also be used to represent user- hiredand raising an exception if insufficient money
defined type valuesdiscussed later in this is available to do so.
columnwhich also have the potential to be large
and unwieldy. Object Orientation
Finally, SQL:1999 has added the notion of
savepoints, widely implemented in products. A In addition to the more traditional SQL features
savepoint is a bit like a subtransaction in that an discussed so far, SQL:1999s development was
application can undo the actions performed after the focussed largelysome observers would say too
beginning of a savepoint without undoing all of the muchon adding support for object-oriented
actions of an entire transaction. SQL:1999 allows concepts to the language.
ROLLBACK TO SAVEPOINT and RELEASE Some of the features that fall into this
SAVEPOINT, which acts a lot like committing the category were first defined in the SQL/PSM standard
subtransaction. published in late 1996specifically, support for
functions and procedures invocable from SQL
statements. SQL:1999 enhances that capability,
Enhanced Security called SQL-invoked routines, by adding a third class
SQL:1999s new security facility is found in its role of routine known as methods, which well get to
capability. Privileges can be granted to roles just as shortly. We wont delve into SQL-invoked functions
they can be to individual authorization identifiers, and procedures in this column, but refer you to an
and roles can be granted to authorization identifiers earlier issue of the SIGMOD Record [6].
and to other roles. This nested structure can
enormously simplify the often difficult job of Structured User-Defined Types
managing security in a database environment.
Roles have been widely implemented by The most fundamental facility in SQL:1999 that
SQL products for several years (though occasionally supports object orientation is the structured user-
under different names); the standard has finally defined type; the word structured distinguishes this
caught up. feature from distinct types (which are also user-
defined types, but are limited in SQL:1999 to being
based on SQLs built-in types and thus dont have
Active Database structure associated with them).
SQL:1999 recognizes the notion of active database, Structured types have a number of
albeit some years after implementations did. This characteristics, the most important of which are:
facility is provided through a feature known as They may be defined to have one or more
triggers. A trigger, as many readers know, is a attributes, each of which can be any SQL type,
facility that allows database designers to instruct the including built-in types like INTEGER,
database system to perform certain operations each collection types like ARRAY, or other structured
and every time an application performs specified types (nested as deeply as desired).
operations on particular tables. All aspects of their behaviors are provided
For example, triggers could be used to log through methods, functions, and procedures.
all operations that change salaries in an employee Their attributes are encapsulated through the use
table: of system-generated observer and mutator
functions (get and set functions) that provide
CREATE TRIGGER log_salupdate the only access to their values. However, these
BEFORE UPDATE OF salary system-generated functions cannot be
ON employees overloaded; all other functions and methods can
REFERENCING OLD ROW as oldrow be overloaded.
NEW ROW as newrow Comparisons of their values are done only
FOR EACH ROW through user-defined functions.
INSERT INTO log_table They may participate in type hierarchies, in
VALUES (CURRENT_USER, which more specialized types (subtypes) have all
oldrow.salary, attributes of and use all routines associate with
newrow.salary) the more generalized types (supertypes), but may
add new attributes and routines.
Triggers can be used for many purposes, not just
logging. For example, you can write triggers that
Lets look at an example of a structured type Functions vs Methods
definition:
SQL:1999 makes an important distinction between
CREATE TYPE emp_type ordinary SQL-invoked functions and SQL-invoked
UNDER person_type methods. In brief, a method is a function with several
AS ( EMP_ID INTEGER, restrictions and enhancements. Lets summarize the
SALARY REAL ) differences between the two types of routine:
INSTANTIABLE Methods are tightly bound to a single user-
NOT FINAL defined type; functions are not.
REF ( EMP_ID ) The user-defined type to which a method is
INSTANCE METHOD bound is the data type of a distinguished
GIVE_RAISE argument to the method (the first, undeclared
( ABS_OR_PCT BOOLEAN, argument); no argument of a function is
AMOUNT REAL ) distinguished in this sense.
RETURNS REAL Functions may be polymorphic (overloaded), but
a specific function is chosen at compile time by
This new type is a subtype of another examining the declared types of each argument
structured type that might be used to describe persons of a function invocation and choosing the best
in general, including such common attributes as name match among candidate functions (having the
and address; the new emp_type attributes include same name and number of parameters); methods
things that plain old persons dont have, like an may also be polymorphic, but the most specific
employee ID and a salary. Weve declared this type type of their distinguished argument, determined
to be instantiable and permitted it to have subtypes at runtime, allows selection of the exact method
defined (NOT FINAL). In addition, weve said that to be invoked to be deferred until execution; all
any references to this type (see the discussion on REF other arguments are resolved at compile time
types below) are derived from the employee ID based on the arguments declared types.
value. Finally, weve defined a method (more on this Methods must be stored in the same schema in
later) that can be applied to instances of this type. which the definition of their tightly-bound
SQL:1999, after an extensive flirtation with structured type is stored; functions are not
multiple inheritance (in which subtypes were allowed limited to a specific schema.
to have more than one immediate supertype), now Both functions and methods can be written
provides a type model closely aligned with Javas in SQL (using SQL/PSMs computationally-complete
single inheritance. Type definers are allowed to statements) or in any of several more traditional
specify that a given type is either instantiable (in programming languages, including Java.
other words, values of that specific type can be
created) or not instantiable (analogous to abstract Functional and Dot Notations
types on other programming languages). And, Access to the attributes of user-defined types can be
naturally, any placesuch as a columnwhere a done using either of two notations. In many
value of some structured type is permitted, a value of situations, applications may seem more natural when
any of its subtypes can appear; this provides exactly they use dot notation:
the sort of substitutability that object-oriented
programs depend on. WHERE emp.salary > 10000
By the way, some object-oriented
programming languages, such as C++, allow type while in other situations, a functional notation may be
definers to specify the degree to which types are more natural:
encapsulated: an encapsulation level of PUBLIC
applied to an attribute means that any user of the type WHERE salary(emp) > 10000
can access the attribute, PRIVATE means that no
code other than that used to implement the types SQL:1999 supports both notations; in fact,
methods can access the attribute, and PROTECTED they are defined to be syntactic variations of the same
means that only the types methods and methods of thingas long as emp is a storage entity (like a
any subtypes of the type can access the attribute. column or variable) whose declared type is some
SQL:1999 does not have this mechanism, although structured type with an attribute named
attempts were made to define it; we anticipate it to be
salaryor there exists a function named
proposed for a future revision of the standard.
salary with a single argument whose data type is define a table containing a column named manager
the (appropriate) structured type of emp. whose values were references to rows in a typed table
Methods are slightly less flexible than of employees, it would look something like this:
functions in this case: Only dot notation can be used
for method invocationsat least for the purposes of manager REF(emp_type)
specifying the distinguished argument. If salary
were a method whose closely bound type were, say, A value of a REF type either identifies a row
employee, which was in turn the declared type of a in a typed table (of the specified structured type, of
column named emp, then that method could be course) or it doesnt identify anything at allwhich
invoked only using: could mean that its a dangling reference left over
after the row that it once identified was deleted.
emp.salary All REF types are scoped so that the table
that they reference is known at compilation time.
A different method, say give_raise, can During the development of SQL:1999, there were
efforts made to allow REF types to be more general
combine dot notation and functional notation:
than that (for example, any of several tables could be
emp.give_raise(amount) in the scope, or any table at all of the appropriate
structured type would be in the scope even if the
table were created after the REF type was created);
ObjectsFinally however, several problems were encountered that
Careful readers will have observed that we have could not be resolved without further delaying
avoided the use of the word object so far in our publication of the standard, so this restriction was
description of structured types. Thats because, in adopted. One side effect of the restriction, possibly a
spite of certain characteristics like type hierarchies, beneficial effect, is that REF types now behave very
encapsulation, and so forth, instances of SQL:1999s much like referential integrity, possibly easing the
structured types are simply values, just like instances task of implementing this facility in some products!
of the languages build-in types. Sure, an employee
value is rather more complex (in appearance, as well Using REF Types
as in behavior) than an instance of INTEGER, but its
You shouldnt be surprised to learn that REF types
still a value without any identity other than that
can be used in ways a little more sophisticated than
provided by its value.
merely storing and retrieving them.
In order to gain the last little bit of
SQL:1999 provides syntax for following a
characteristic that allows SQL to provide objects,
reference to access attributes of a structured type
there has to be some sense of identity that can be
value:
referenced in a variety of situations. In SQL:1999,
that capability is supplied by allowing database SELECT emps.manager->last_name
designers to specify that certain tables are defined to
be typed tablesthat is, their column definitions
The pointer notation (->) is applied to a
are derived from the attributes of a structured type:
value of some REF type and is then followed into
the identified value of the associated structured
CREATE TABLE empls OF employee
typewhich, of course, is really a row of the typed
table that is the scope of the REF type. That
Such tables have one column for each
structured type is both the type associated with the
attribute of the underlying structured type. The
REF type of the manager column in the emps table
functions, methods, and procedures defined to
operate on instances of the type now operate on rows and the type of that other table (whose name is
of the table! The rows of the table, then, are values neither required nor apparent in this expression).
ofor instances ofthe type. Each row is given a However, that structured type must have an attribute
unique identity that behaves just like a OID (object named last_name, and the typed table thus has a
identifier) behavesit is unique in space (that is, column of that name.
within the database) and time (the life of the
database). Schedules and Futures
SQL:1999 provides a special type, called a SQL:1999 is not yet a standard, although its well on
REF type, whose values are those unique identifiers. its way to becoming one. Last year, what is called the
A given REF type is always associated with a Final Committee Draft (FCD) ballot was held for
specified structured type. For example, if we were to
four parts of the SQL specifications (see references Judy Dillman (USA; CA)
[1], [2], [4], and [5]). In November, 1998, the final Rdiger Eisele (Germany; Digital and
round of the Editing Meeting was held for those independent consultant)
parts. The changes to the specifications have been Andrew Eisenberg (USA; Digital, Oracle, and
applied by the Editor (Jim Melton) and are now being Sybase)
reviewed by Editing Meeting participants. When Chris Farrar (USA; Teradata and Compaq)
those reviews are completed, those four Len Gallagher (USA; NIST)
specifications will be submitted for one last ballot Luigi Giuri (Italy; Fondazione ugo Bordoni)
(called a Final Draft International Standard, or FDIS, Keith Hare (USA; JCC)
ballot), the result of which is either approve and Bruce Horowitz (USA; Bellcore)
publish without change or disapprove and go back Bill Kelly (USA; UniSQL)
to FCD status. All participants currently anticipate Bill Kent (USA; HP)
that the result will be to approve and publish, Krishna Kulkarni (USA; Tandem, Informix, and
resulting in a revised standard sometime in mid-1999. IBM)
Another part of SQL, SQL/CLI (see Nelson Mattos (USA; IBM)
reference [3]), is also being revised and has just Jim Melton (USA; Digital and Sybase)
undergone an FCD ballot. It is expected that it will be Frank Pellow (Canada; IBM and USA;
published later in 1999 as a revision of the CLI-95 Microsoft)
standard. Baba Piprani (Canada; independent consultant)
Its hard to know what the future will bring, Peter Pistor (Germany; IBM)
but both the ANSI and ISO groups are committed to Mike Pizzo (USA; Microsoft)
avoiding the lengthy process that resulted in Jeff Richie (USA; Sybase and IBM)
SQL:1999. We all believe that 6 years is simply too Phil Shaw (USA; IBM, Oracle, and Sybase)
long, especially with the world working in web Kohji Shibano (Japan; Tokyo International
time more and more. Instead, plans are being University and Tokyo University of Foreign
developed that will result in revisions being issued Studies)
roughly every three years, even if the technical Masashi Tsuchida (Japan; Hitachi)
enhancements are somewhat more modest than those Mike Ubell (USA; Digital, Illustra, and
in SQL:1999. Informix)
In addition to evolving the principle parts of Murali Venkatrao (USA; Microsoft)
the SQL:1999 standard, additional parts of SQL are Fred Zemke (USA; Oracle)
being developed to address such issues as temporal Each of these people contributed in some
data, the relationship with Java (explored in the significant way. Some of them designed major
previous issue of the SIGMOD Record), and aspects of the architecture of SQL:1999, others
management of external data along with SQL data. focussed on specific technologies like the call-level
interface (SQL/CLI), while others worked on very
Recognition of Individual focussed issues, such as security. They are allas are
other contributors not mentioned hereto be
Contributors congratulated on a large job well done.
There have been many, many people involved in the
development of SQL:1999 over the years its References
development occupied. While we dont have the
space to mention everybody who participated in the [1] ISO/IEC 9075:1999,Information technology
committees during its development, we do think it Database languagesSQLPart 1: Framework
appropriate to mention at least the names of people (SQL/Framework), will be published in 1999.
who wrote significant numbers of change proposals [2] ISO/IEC 9075:1999,Information technology
or simply wrote significant proposals. Database languagesSQLPart 2: Foundation
Mihnea Andrei (France; Sybase) (SQL/Foundation), will be published in 1999.
Jon Bauer (USA; Digital and Oracle) [3] ISO/IEC 9075:1999,Information technology
David Beech (USA; Oracle) Database languagesSQLPart 3: Call-Level
Ames Carlson (USA; HP and Sybase) Interface (SQL/CLI), will be published in 1999.
Stephen Cannan (Netherlands; DCE Nederland [4] ISO/IEC 9075:1999,Information technology
and James Martin Consulting) Database languagesSQLPart 4: Persistent
Paul Cotton (Canada; IBM) Stored Modules (SQL/PSM), will be published in
Hugh Darwen (UK; IBM) 1999.
Linda deMichael (USA; IBM)
[5] ISO/IEC 9075:1999,Information technology
Database languagesSQLPart 5: Host
Language Bindings (SQL/Bindings), will be
published in 1999.
[6] New Standard for Stored Procedures in SQL,
Andrew Eisenberg, SIGMOD Record, Dec.1996

The SQL specifications will be available in the

United States from:

American National Standards Institute

Attn: Customer Service
11 West 42nd Street
New York, NY 10036
USA

Phone: +1.212.642.4980

It will be available internationally from the

designated National Body in each country or from:
International Organization for Standardization
1, rue de Varemb
Case postale 56
CH-1211 Genve 20
Switzerland

Phone: +41.22.749.0111

Web References
American National Standards Institute (ANSI)
http://web.ansi.org

International Organization for Standardization (ISO)

http://www.iso.ch

JTC1 SC32 Data Management and Interchange

http://bwonotes5.wdc.pnl.gov/SC32/JTC1SC32.nsf

National Committee for Information Technology

Standards (NCITS)
http://www.ncits.org

NCITS H2 Database
http://www.ncits.org/tc_home/h2.htm