Attribute

The term attributes comes up often in both SGML and object-oriented discussions. Let’s start with the SGML definition: ISO 8879 section 4.9 defines an attribute as “A characteristic quality, other than type or content.” SGML recognizes two levels of attributes: primary and secondary. Primary attributes are the IDs unique to each declared element type that are sometimes called “generic identifiers” or just “GIs.” These are used in the “tags” that identify the start and, if necessary, the end of elements. Generic identifiers usually do this by including this attribute in angle brackets and by preceding the closing tag’s element name with a slash. For example, the second-level headers declared by many DTDs have a primary attribute of “h2” that is used in the <H2> and </H2> markup tags.

Additional attributes, such as the HTML anchor element’s NAME attribute, which assigns a name to the anchor so that it can serve as a jump destination, or its attribute, which identifies a jump destination if the anchor is clicked, are considered to be secondary attributes. When SGML people talk about an element’s attributes, they’re usually talking about these secondary attributes.

An object-oriented system using SGML data would use each element’s generic identifier to figure out which object class it belongs to and then use the secondary attributes as “attributes” in the object-oriented sense—as a set of values associated with each instance of that element type’s “class.” For example, the HTML A element’s secondary attribute HREF, which identifies a location where the cursor should jump if the text tagged as an A element is clicked, is a value giving information about that tagged text.

State

An object’s state is its current collection of attribute values. For an aggregate object (an object composed of a combination of other objects) such as an SGML document, this would include the values of its component objects’ attributes—for example, a recipe’s state would include the attribute values of its title, ingredients, and instructions’ components. Determining possible object states and the role of state transitions plays a large role in many object-oriented analysis/object-oriented development systems (or, as they’re more commonly known, “OOA/OOD methodologies”). The state transitions of a system are what make good analysis and design so important, because lack of control over these transitions, especially in a multi-user system, leads to the kind of concurrency problems that cause unpredictable behavior.

State transitions play a small role in an SGML system until you build an editor—especially a multi-user editor—on top of an object-oriented SGML system. Unlike, for example, a car undergoing assembly, there are few state transitions to plan around for an SGML object once its data and components are assigned at object creation time.

SGML data is typically used as a source format that makes it easy to create multiple different output formats, so transformation of the data is done to copied data being output, while the source is left alone. When writing code to define behavior in an SGML system that allows editing of the data, especially multi-user editing, keeping track of various states plays a more important role. The developer should be able to leave this work to an object-oriented database manager (OODBMS) that performs object locking and other database management functions that allow trouble-free multi-user access. (You’ll learn about the tremendous benefits that an OODBMS can offer in the “Object-Oriented Technology and the Future of SGML Development” section.)

To keep this discussion simple, we’ll only concern ourselves with static SGML data that does not change when a program is run. This doesn’t sacrifice much, because of the number of SGML applications that make changes to a copy of the data in order to output data in some other format. So for now, don’t worry about state changes.

Behavior

Booch defines behavior as “how an object acts and reacts, in terms of its state changes and message passing.” Defining an object’s behavior means writing code for each class to respond to messages sent to objects of that class. A block of code written to respond to a given message is analogous to a function or procedure written in a more traditional language; the “message” is equivalent to the function call.

As we saw, good DTD design deliberately avoids the definition of element behavior to allow the most flexibility possible to developers using that data, so defining behavior for SGML elements is the principle step toward treating SGML data as part of an object-oriented system. Because this assignment of behavior can be done by an external application that can leave the data and its structure alone, you can maintain the integrity of the SGML data, since you’re only using the DTD as a starting point and then externally defining behavior to go with each of its elements.

Table 31.2 summarizes the correlations between object-oriented and SGML terms.