XML Query Language (XQL)		Table of contents		Indexes		Meta-analysis of clinical documents for principled markup of Medical Records

Graphic Element Markup

Mark Roberts

Software Engineering Specialist

InfoSphere, Inc.
Phone: (817) 731-0995
Fax: (817) 731-0997 Web: robertsm@infosphere-inc.com 6300 Ridglea Place
Suite 801
Fort Worth Texas 76116 USA

Biographical notice:

Mark D. Roberts is a software engineering specialist at InfoSphere, Inc. He has been involved in the development of solutions for storage and transmission of graphical information since 1983. His recent activity has been in development of the graphical element markup language. He has also been deeply involved in implementation of solutions for SGML document production and delivery since 1991.

ABSTRACT:

InfoSphere, Inc. has created a language for modeling graphical content. InfoSphere’s GEM (Graphic Element Markup) language utilizes strongly-typed object structures that are associated with a core set of graphical primitives. These object structures are implemented as a set of architectures and may be represented in either SGML (Standard Generalized Markup Language) or the newer XML (eXtensible Markup Language) . A vendor-neutral strategy was employed for GEM development. The result permits natural integration of graphic information with other document content. Applications can then utilize graphical information as normal content markup in a document stream. GEM exposes the graphical information to parsers, search tools, and grove-based information processing facilities. Therefore, GEM provides a method for seamless integration of text and graphical content.

Introduction

Graphical information is naturally object-oriented. Pictures are constructed by placing various objects such as lines and arcs within a specific coordinate system. The details, or properties, of these objects regarding position, orientation, color, and texture can also be represented as objects. In an object-oriented representation, these property objects would be children, or sub-objects, of the parent object. The SGML standard offers rich semantics that facilitate construction of a modeling language suitable for representation of graphical information.

InfoSphere, Inc. has created such a graphics modeling language by representing graphical primitives as generic architectures which may be utilized in a document structure defined by a Document Type Definition (DTD). The Graphic Element Markup (GEM) language is a strongly-typed, object-oriented language for representing graphical constructions in both 2-D and 3-D. There are simple objects to describe object properties and more advanced objects to describe graphical primitives such as lines and arcs. More sophisticated objects are used to describe other shapes, surfaces, and collections of objects.

Purpose

2-D
3-D
graphic

language

two-dimensional

This is a description of the GEM language. GEM is an object language that will permit representation of both 2-D and 3-D graphical information in either SGML or XML . The GEM language is also extensible in that the core graphic data is defined by a series of architectures that may be customized by the Document Architect to fit specific structural requirements. InfoSphere intends for the GEM language to be an open standard for graphics markup and exchange. It can be utilized in areas where rich markup and granular structure are desired to create graphical components that are integral with other document content.

The GEM language was created to establish graphical elements in SGML that could be naturally integrated in the document stream with other SGML content. In other words, using GEM, graphic information can occur in context with text information in a single document. This reduces the traditional barrier that has existed between graphic and text content. GEM also permits references and links to be used to describe relationships between SGML elements regardless of the content type. This powerful capability allows applications to utilize graphical elements as navigation aids to the reader as well as for graphical actions to be triggered by links embedded within text elements. For example, web applications can utilize common ID/IDREF functionality to express links between text and graphic content that will be traversed by the browser in response to the user’s mouse click over the graphic object. This traversal is based on an intelligent hit test of the object rather than a hot-spot or defined region technique.

Background

Generally, graphical components of a document are segregated from the main document content. This segregation is necessary because the graphical information is not in the same format as the document itself. For many SGML environments, reference tags and entities are used to indicate the location of graphical content in the document flow. However, because the image is in a non-SGML format, information in the graphic data cannot be easily utilized by the SGML processor for searching, content verification, and user interaction unless additional information is provided in the form of attributes, meta-data, hot-spot overlays, or companion files. Inserting and maintaining this type of additional information is time-consuming, costly, and typically creates significant technical challenges and bottlenecks in the document production cycle.

For many documents, graphical content is a pictorial depiction of the text. For documents that will be published for use in an online or interactive application, the user will be best served if complex procedures or lengthy parts lists utilize a figure for navigation purposes. By displaying a process flowchart or an exploded assembly view, the user could easily indicate the point of interest with a simple click of the mouse. To permit this type of interaction, the relationships between the graphical components and the text components must be defined in some manner. Current techniques for this compensate for the inability of the graphic components themselves to describe those relationships.

GEM Overview

The GEM language was designed to allow integration of graphics and text in the same SGML document instance. GEM is intended to facilitate:

The ability to search for data contained within a graphic.
The ability to interrogate, utilize, and verify graphic structure using a standard SGML tools.
The ability to use hierarchy to establish ownership and inheritance within a graphic.
The ability to link graphic elements to both other graphic elements and text elements using standard link mechanisms compatible with other types of SGML content (i.e., ID/IDREF and HyTime).
Dynamic updating of graphic information (i.e., syndicated content updates)

In the GEM language, graphical elements are represented as object structures associated with graphical primitives. These primitives are implemented as a series of architectures.

GEM is designed to be flexible. GEM architectures may be integrated and customized by a Document Architect in the DTD to conform to their specific implementation requirements. The minimum definition requirements for each primitive depend on the object being represented. These definitions will be presented later in this document.

GEM Utilization

The overall goal of the GEM language was to create an object-based implementation of graphical elements that could be used like their text counterparts in SGML or XML . SGML document structure expressed in the DTD establishes data models for containing text information. GEM allows those data models to contain graphical information as well. Using GEM objects, hierarchy can be used to establish ownership, so that a phrase contained within a rectangle could be interpreted in a flowchart document as the text label of the graphical node. Utilization of GEM in this way would yield a rich data repository containing both text and graphical information in SGML.

This integrated environment in which to store both graphics enables intelligent search and query tools to interrogate the data model, regardless of content, and correctly identify relevant information. Applications can then create composite documents (or dynamically assembled documents) from stored objects containing text or graphics.

Current efforts in the industry are focused on Web delivery of vector graphic information. Most proposals to date are strongly oriented toward compact utilization of XML for internet exchange and may ultimately merge into one recommendation from W3C known as SVG.

The GEM language is complementary toward these efforts in that it is built to provide rich content markup for graphical information that can be easily down-translated into a more compact data stream for web delivery or other publication processing. However, that same rich content markup for graphical information is also suitable for translation into other graphical forms as well. Therefore, GEM permits ultimate flexibility in expression of a data exchange language where text and graphic content can be naturally integrated. InfoSphere intends to publish its language specification as an open standard and has offered its viewing applications for Netscape and Internet Explorer as freeware products.

A First Look at GEM

This first example is divided into three progressive illustrations to reveal different aspects of the GEM language.

Illustration 1-A

The first illustration shows the SGML structure for a line that is 50 pixels long.

Simple Line Illustration

<line gel=”line”>
<drawdata gel=”geldef”>
<point gel=”point”>{0.00, 0.00}</point>
<point gel=”point”>{50.00, 0.00}</point>
</drawdata>
</line>

Examination of the illustration above would reveal that thegel attribute is used to associate each SGML element with its respective graphic type. This is the mechanism used in the GEM language to associate the graphic markup with graphic behavior derived from the architectural forms.

Illustration 1-B

Inspecting the line element above, two points can be found within the defining element wrapper calleddrawdata . The concept of the defining element wrapper will be discussed later. The two points are required by the line architecture and define the endpoints of the current line. However, notice that each point is itself an object and may therefore be defined elsewhere and referenced here by some type of reference or link as shown in the following illustration:

<line gel=”line”>
<drawdata gel=”geldef”>
<xref refid=”startpoint”>
<point id=”endpoint” gel=”point” style=”cr”>{50.00, 0.00}</point>
</drawdata>
</line>

A Point defines a particular location in the current coordinate system. However, points can be specified in absolute or relative polar and Cartesian coordinates.

In this case, the GEM interpreter would validate the object referenced by thexref element (named “startpoint”) to make sure it was actually a valid point in order to validate the line instance. It would then interpret the line according to the two endpoints. This feature makes it convenient for users to create graphic elements that have a position dependent on another element. An application based on this example could be used to dynamically update line graphs from Dow-Jones every minute where each new line segment could begin where the previous point ended by simply referencing the name of the previous endpoint.

It should also be noted that the style attribute shown in the previous illustration for the point labeled “endpoint” would be interpreted by the GEM interpreter as a “cartesian-relative” coordinate value. This would cause the coordinate data {50.00, 0.00} to be evaluated as a relative move of 50 pixels in the X direction and 0 pixels in the Y direction from the location of the previous point. For points, the valid style types are shown in the following table.

Valid Point Styles
Style Attribute Value	Definition	Semantics
c	Cartesian Absolute (Default)	{X, Y, [Z]}
p	Polar Absolute	{R, θ, [φ]}
cr	Cartesian Relative	{Xr, Yr, [Zr]}
pr	Polar Relative	{Rr, θr, [φr]}

For the last illustration in this example, suppose it was necessary for the line to be shown in red. In GEM this can be accomplished by adding apen object to the line as is shown below:

<line gel=”line”>
<drawdata gel=”geldef”>
<xref refid=”startpoint”>
<point id=”endpoint” gel=”point”>{50.00, 0.00}</point>
<pen gel=”pen”>
<color gel=”color”>{255, 0, 0}</color>
</pen>
</drawdata></line>

Notice that the color is actually defined by acolor element that occurs as a child (or in the context of) thepen element. More detail regarding the requirements of each object will be given later.

GEM Implementation Strategy

The following guidelines were applied in the development of the graphic element markup language:

Definitions

Convenient Representation: GEL primative forms should allow convenient representation forms for commonly used graphical types.
Object Oriented: Discreet object types shall be used to represent all quantifiable object behavior.
SGML Based: Object types shall be represented in SGML [ISO 8879]
XML Compatible: Object representations shall not use any SGML representation that cannot be directly translated into XML
Convenient Representation: Object types should allow convenient and consistent forms for representation of commonly used graphic types.
Relational: It shall be possible to express relationships between all object types to each other and to non-graphical structures as needed using traditional cross-references and HyTime application features
Architecture Based: Graphic object types shall be defined as an architecture that can be integrated with user document types according to the normal rules for defining and utilizing architectural types
Extensible: The content model for each graphic object should be extensible to permit customization based on user requirements
Flexible: Objects shall offer multiple definition modes to permit convenient representation of the graphic elements

These guidelines have been used by InfoSphere to develop a set of architectures that define graphical primitives used in vector graphic images.

Discreet Element Strategy

As illustrated above, the GEM permits defining elements of one object to be referenced by other objects. Using this strategy, graphic objects can share a color definition, pen style, or important anchor location through use of a common cross-reference tag. These references are no different than the references used by text components to reference another chapter or section in the same document.

Multiple Definition Schemes

Many GEM architectures permit multiple definition schemes for their respective graphic primitives. Accommodation of multiple definition schemes facilitates easy conversion from existing vector graphic data formats and convenient modeling of graphical data based on computed values. For example, the primitive architecture for anarc allows users to define an Arc through the use of:

A center point and a radius value
A center point and one edge point
Three discreet points on the Arc

Circular Arc with Unit Radius

For example, the following three instances would create exactly the same circular arc:

Style 1: Center-Edge Points (given by a line)

<Arc style=”1">
<ArcData>
<Line>
<DrawData>
<Point>{0.00, 0.00}</Point>
<Point>{1.00, 0.00}</Point>
</DrawData>
</Line>
<Angle>0.00</Angle>
<Angle>180.00</Angle>
</ArcData>
</Arc>

Style 2: Center-Radius

<Arc style=”2">
<ArcData>
<Point>{0.00, 0.00}</Point>
<Radius>1.00</Radius>
<Angle>0.00</Angle>
<Angle>180.00</Angle>
</ArcData>
</Arc>

Style 3: Three Point

<Arc style=”3">
<ArcData>
<Point>{1.00, 0.00}</Point>
<Point>{0.00, 1.00}</Point>
<Point>{-1.00, 0.00}</Point>
</ArcData>
</Arc>

Application Example

In this example, bothwing andtire elements will create a graphic object but the content models of each object have been customized to reflect structure that is logical for the specific object. In this case wings have planforms (outline shapes as viewed from above) and cross-section views whereas tires have tread-views, and street-views. Both objects contain other elements called cross-section, designation and description. One specific benefit of Graphic Markup illustrated by this example is that the structure of the document itself may be validated with a standard SGML parser regardless of the fact that some of these elements actually describe graphical information.

<!ELEMENT  wing    - -  (planform, cross-section, designation, description) >
<!ATTLIST  wing    gel  CDATA      #FIXED “canvas”>
<!ELEMENT  tire    - -  (tread-view, street-view, cross-section, designation, description) >
<!ATTLIST  tire    gel  CDATA      #FIXED “canvas”>

Architecture Overview

Table 1 defines the architectures currently available in the GEM language. These architectures may be referenced and renamed in the application DTD. Table 2 segregates the object definitions into three groups, Basic, Simple, and Compound according to the definitions found below:

Definitions

Basic: Allow specification of certain data types. The basic types typically contain only PCDATA content and are used as construction elements for Simple and Compound types.
Simple: Main geometric primitives. Simple types often have multiple definition modes to permit flexibility in the GEM language.
Compound: Compound types are used to indicate groups of elements that need to be manipulated as a single unit rather than separate elements.

Note:

$#160;

The simple types shown in table 2 are only two-dimensional. Three-dimensional types are discussed in appendix B, but have only been used experimentally.

Architecture Types for Graphic Elements
Basic Types
Architecture Name	Definition
angle	Used to specify angles for rotation, arc endpoints, and items in polar notation.
color	Used to specify color values. Style attributes are used to indicate which color model should be applied to the data values.
dash	Used to define a dash object. Dash objects describe line drawing properties for the parent object.
layer	Used to indicate the active drawing layer for the parent object.
length	Used to define a length value. Units are implied by the canvas or specified in an attribute.
radius	Used to specify radius values for arcs, rounded rectangles, and items in polar notation.
x-pnt	Used to specify a Cartesian coordinate X value.
y-pnt	Used to specify a Cartesian coordinate Y value.
z-pnt	Used to specify a Cartesian coordinate Z value.
Simple Types
arc	Used to define a circular arc object. An arc has 3 definition modes.
Center-Edge: Given by two discreet points or a line element. The first point defines the center of the arc, and the second point defines a point on the arc.
Three-point: A circular arc on the X-Y plane. Point order implies the draw direction.
Center-Radius: Given by a single point and a radius value.
arrow	Used to define the arrow dimensioning values of Base Angle, Tip Angle, and Tip Length.
bezier	Used to define a Bezier curve object. Requires four discreet points. The first and last of which are taken as the end points of the curve. The middle two points are used as control points for the curve.
conn	Used to define a connector object. These objects are lines (or polygonal lines) that are attached to a specific handle ID of the referenced object. Connectors are convenient because when the referenced object is moved, the connector stays attached to the object.
ellipse	Used to define an elliptical object. There are 4 definition modes for the ellipse object.
Bounding Box: A rectangle object is given to define the boundaries of the ellipse.
Axes-Reference: Given by two line elements. The longest line element is taken as the semi-major axis. The shorter line segment is taken as the semi-minor axis.
Foci-length: Given by two discreet points or a line element and a length element.
	Conjugate-Diameters: Given by two line segments.
fill	Used to define a fill object.
line	Used to define a line object.
parabola	Used to define a parabolic object. A parabola as two definition modes:
Focus-Directrix: Given by a point and a line element.
Rectangle: Used to define the bounding box of the active range of the parabola.
pen	Used to define a pen object.
point	Used to indicate a specific point on the current canvas in either Cartesian or polar notation. Points have a mixed content notation that permits the GEM short-hand notation for a coordinate value (i.e., two or three delimited floating point values enclosed in curly braces) or the use of discreet x-pt, y-pt, z-pt for Cartesian coordinates and radius, angle, angle for polar coordinates.
raster	Used to specify a raster image type.
rectangle	Used to specify a rectangle type. A rectangle has 2 definition modes.
Two-Point: Given by two discreet points or a line element with an optional angle object.
Center-Size: Given by one point and two length values that are taken as width and height respectively.
spline	Used to define a closed Polygon or Spline object. A degree attribute is used to control the smoothing algorithm. A spline of degree zero is taken to be a Polygon.
text	Used to define a graphical text object. Graphical text objects are simple text strings intended for annotation purposes. The content model of graphical text objects is restricted to PCDATA.
Compound Types
canvas	Used to specify a graphical coordinate system within the SGML data stream. The Canvas data type is the container for all other graphic content.
group	Used to specify an un-named group of graphic elements. Once grouped, all elements contained in the group can be manipulated as one object through translations, rotations, and scaling.
symdef	Used to specify a named group of Graphic Elements. Symbols are significantly different from a group in that they may be defined once and instanced many times in a given document. Each instance or reference can specify a unique position, scale, and rotation that will modify the precise presentation of the symbol each time it is used.
symbol	Used to indicate an instance of a symbol. This object uses attributes to control position, scaling, and orientation of the referenced object. This facilitates the use of an EMPTY element for this reference purpose. Symbols are also used to include (by reference) an external GEM file as a single object in the current document. This allows users to create a series of GEM files that effectively operate as a library of symbols that may be used “by reference” in other documents.

The Defining Elements

In GEM, the architectures for many of the Simple Types are extensible. However, to avoid ambiguous content models, the information needed to construct a valid graphical object is contained within a wrapper element. The wrapper element architecture is calledgeldef and is used to enclose elements that define the parametric data necessary to construct the element.. Elements contained within thegeldef are considered to be the Defining Elements for the current graphical primitive. Data found outside thegeldef architecture will be considered as content for the element.

An Integration Example

To illustrate how GEM can be used as an integral document component, consider the following example. In the example below, the link element is used to establish a simple one-way relationship between elements in the graphic and elements in the text content. The graphic data below would be rendered on the screen as:

Flowchart Example

<flowchart gel=”group”>
<drawdata gel=”geldef”>
<point gel=”point”>{0.00, 0.00}</point>
</drawdata>
<process id=”step1g” gel=”rect”>
<drawdata gel=”geldef”>
<point gel=”point”>{250.00, 50.00}</point>
<point gel=”point”>{350.00, 100.00}</point>
</drawdata>
<text gel=”text”><link refid=”step1">Step 1</link></text>
</process>
<arrow gel=”line”>
<drawdata gel=”geldef”>
<point gel=”point”>{300.00, 100.00}</point>
<point gel=”point” style=”cr”>{0.00, 100.00}</point>
<pen gel=”pen” style=”arrow”>
</pen>
</drawdata>
</arrow>
<process id=”step2g” gel=”rect”>
<drawdata gel=”geldef”>
<point gel=”point”>{250.00, 200.00}</point>
<point gel=”point”>{350.00, 250.00}</point>
</drawdata>
<text gel=”text”><link refid=”step2">Step 2</link></text>
</process>
lt;/flowchart>

<section id=”procedure1">
<step id=”step1">
<title>Read Manual</title>
<p><link refid=”step1g”>Show flowchart</link></p>
.
.
.
</step>
<step id=”step2">
<title>Assemble Tools</title>
<p><link refid=”step2g”>Show flowchart</link></p>
.
.
.
</step>
</section>

In this example, the flowchart contains two process elements. These elements refer to their respective step elements in the text. In a similar manner, the step elements refer to their respective process elements. A viewing application would manage traversal between the text and graphic elements upon user input.

Instead of using direct links between the two document components, perhaps a better method would be to utlize a HyTime ilink to express the relationship between the two objects as shown below:

.
.
.
<xref id=”link1" linkends=”link1 step1 step1g”>
<xref id=”link2" linkends=”link2 step2 step2g”>
.
.
.

Regardless of which link mechanism is utilized, the virtue of expressing the content for both graphic and text components in SGML is that it allows this type of flexibility. Information elements containing both text and graphics can be utilized by virtually any SGML/XML tool for seamless integration of data. The contents of the graphic components are no longer hidden from the parser, formatter, search engine, HyTime engine, or any other SGML-capable facility.

GEM Details

Table 3 contains the specific definition requirements for each object type. The implementation details of this specification can be found in the Default GEM DTD in Appendix A.

Required Content
Basic Types
Architecture	Defining Element Wrapper	Required Content for Valid Definition
angle	No	#PCDATA - (Single Value)
color	No	#PCDATA - (GEM Triple)
dash	No	#PCDATA - (Single Value)
layer	No	#PCDATA - (Single Value)
length	No	#PCDATA - (Single Value)
radius	No	#PCDATA - (Single Value)
x-pnt	No	#PCDATA - (Single Value)
y-pnt	No	#PCDATA - (Single Value)
z-pnt	No	#PCDATA - (Single Value)
Simple Types
arc	Yes	Style 1: Point, Radius (Center-Radius) Style 2: (Line \| (Point, Point)) (Center-Edge) Style 3: (Point, Point, Point) (Three-Point)
arrow	No	Angle, Angle, Length (Base-Angle, Tip-Angle, Length)
bezier	Yes	4 Points First and last point are the curve endpoints. Second and third points are control points.
conn	Yes	None required. Connector objects use attributes to reference their target objects and handle numbers. However, for proper routing, a connector may need a point list, layer, or pen colors specified in the Defining Element wrapper.
ellipse	Yes	Style 1: Rectangle (Bounding Box) Style 2: (Point, Point, Point) (Axis-Reference: Second point is center of ellipse. First and last points are endpoints for the semi-major and semi-minor axes.) Style 3: (Line \| (Point, Point)),Length (Focus Point-Length: This form requires the two focus points and the constant length value of the ellipse to be specified.)
fill	No	(Color*, Angle?, Pattern?) Multiple fill colors can be specified. One color would be interpreted as a solid fill. Two colors would be interpreted as a gradient fill. Angle would specify a hatch pattern or gradient angle. The utilization of the Pattern object would be application dependent.
line	Yes	2 Points End points to the line
parabola	Yes	Style 1: Rectangle Bounding box Style 2: (Point, Line) Focus-Directrix
pen	No	(Length?, Color?, Dash?, Arrow?) All objects modify pen settings for current object. The length value is interpreted as pen width.
point	No	Style 1: #PCDATA (GEM Triple. Interpretation depends on the style attribute. Cartesian, Polar, Absolute, Relative) Style 2: (X, Y, Z?) Expanded Cartesian form allowing discreet data values for each coordinate axis. Style 3: (Radius, Angle, Angle?) Expanded Polar form allowing discreet data values for each polar value radius, theta, phi. Where theta is the angle on the X-Y plane about the Z axis and phi is the angle above or below the X-Y plane.
raster	Yes	Point Initial location of the raster image.
rectangle	Yes	Style 1: (Point, Point, Angle?) The two points indicate the endpoints of the diagonal line drawn from the lower left-hand corner to the upper right-hand corner of the rectangle. The optional angle object specifies the rotation angle of the rectangle. Style 2: (Point, Length, Length, Angle?) Center-Height-Width. The point is taken as the center of the rectangle. The first length value is taken as the width (X-dimension) and the second length value is taken as the height (Y-dimension). The optional angle object specifies the rotation angle of the rectangle.
spline	Yes	(Point, Point, Point+) Multiple point objects are taken as vertices of the spline. Polygonal lines are represented as spline objects with a smoothing degree of zero (0).
text	Yes	None required. The graphical text object does not need any defining elements. Positioning of the text object depends on its parent. However, if the user desires, a point can be specified in the defining element wrapper that will be interpreted as the origin of the text object.
Compound Types
canvas	No	This is the highest level graphic architecture. This architecture establishes the coordinate system for all subsequent graphical content. Graphical elements found outside of the canvas element will not be interpreted graphically.
group	Yes	Point This object allows a collection of objects to be manipulated as one object. The point found in the defining element wrapper is interpreted as the origin of the group.
symdef	No	This architecture simply allows a collection of objects to be associated by a name.
symbol	No	This architecture has no content model. The reference to a named symbol and any manipulation of it is handled through attribute settings.

Appendix 1 - Document Type Definition for Graphic Markup

<!-- InfoSphere Default Graphic DTD

Public Name : GraphicDTD
Public ID   : -//InfoSphere//DTD Graphic V3//EN

Graphic DTD. This DTD contains the structure to store a graphic image
as part of an SGML document. Graphic elements are constructions of other
primitives and base types but may be integrated with other types.

InfoSphere, Inc. 1999
-->

<!ENTITY % PointData  "Point | Xref"                                  >
<!ENTITY % LineData   "Line | Xref"                                   >

<!ENTITY % GP.ex      "                                              >
<!ENTITY % GelPar     "Text"                                          >
<!ENTITY % GelBasic   "Pen | Fill | Layer | Length | Height | Width |
Radius | Angle"                                 >
<!ENTITY % GelSimple  "Point | Line | Connector | Polygon | Rectangle |
Ellipse | Parabola | Arc | Spline | Curve"      >
<!ENTITY % GelComplex "Box | Cone | Cylinder | Sphere | Parabolid |
Ellipsoid | Surface"                            >
<!ENTITY % GelDefObj  "%GelBasic; | %PointData; | Line | Rectangle"   >
<!ENTITY % GelObjects "Group | %GelSimple; | Symbol | Symref |
RasterData | %GelPar;"                          >
<!ENTITY % Gels       "%GelBasic; | %GelObjects;"                     >

<!ENTITY % Graphics   "Canvas"                                        >

<!--
Primitive Type:  Canvas

Base primitive for all graphic construction. The canvas defines
the coordinates system for the graphic image. All other graphic
primitives must be contained within a canvas. A canvas may have
both an ID and a Window name associated.

Attribute Data:
gel     : Attribute to associate given element name to specific
primitive type.
gelid   : Attribute to contain a persistent GKS-style Segment ID.
xrange  : Xmin, Xmax :: Define (in order) the minimum and
maximum X values for the canvas.
yrange  : Ymin, Ymax :: Define (in order) the minimum and
maximum Y values for the canvas.
zrange  : Zmin, Zmax :: Define (in order) the minimum and
maximum Z values for the canvas. This attribute
is optional. If it is omitted, the canvas is assumed
to be 2-D only and the X-Y plane will be parallel
to the display surface. (Viewing direction will
be normal to the X-Y plane.)
bgcolor : Background color for the canvas.
border  : Width of border around canvas edge in points.
Default is 0.
bcolor  : Color of border around canvas edge.
Default is BGcolor.
units   : Allows users to specify the default unit values for
the canvas coordinates.
wname   : Window name.
-->
<!ELEMENT Canvas    - -   (%Gels;)*                                   >

<!ATTLIST Canvas    id      ID      #IMPLIED
gel     CDATA   #FIXED  "canvas"
gelid   NUMBER  #IMPLIED
linkid  CDATA   #IMPLIED
xrange  CDATA   #REQUIRED
yrange  CDATA   #REQUIRED
zrange  CDATA   #IMPLIED
bgcolor CDATA   #IMPLIED
border  CDATA   #IMPLIED
bcolor  CDATA   #IMPLIED
units   CDATA   #IMPLIED
wname   NAME    #IMPLIED
>

<!--
Basic Primitive Types:  Length, Radius, Angle, X, Y, Z, Layer

These simple types are place holders for defining values of other
graphic elements. Some elements have a units attribute
-->
<!ELEMENT Length    - -   (#PCDATA)                                   >
<!ATTLIST Length    gel     CDATA   #FIXED "length"
gelid   NUMBER  #IMPLIED
units   CDATA   #IMPLIED
>

<!ELEMENT Offset    - -   (#PCDATA)                                   >
<!ATTLIST Offset    gel     CDATA   #FIXED "length"
gelid   NUMBER  #IMPLIED
units   CDATA   #IMPLIED
>

<!ELEMENT Radius    - -   (#PCDATA)                                   >
<!ATTLIST Radius    gel     CDATA  #FIXED  "radius"
gelid   NUMBER  #IMPLIED
units   CDATA   #IMPLIED
>

<!ELEMENT Angle     - -   (#PCDATA)                                   >
<!ATTLIST Angle     gel     CDATA   #FIXED "angle"
gelid   NUMBER  #IMPLIED
units   CDATA   #IMPLIED
>

<!ELEMENT X         - -   (#PCDATA)                                   >
<!ATTLIST X         gel     CDATA   #FIXED  "x-pt"
gelid   NUMBER  #IMPLIED
>

<!ELEMENT Y         - -   (#PCDATA)                                   >
<!ATTLIST Y         gel     CDATA   #FIXED  "y-pt"
gelid   NUMBER  #IMPLIED
>

<!ELEMENT Z         - -   (#PCDATA)                                   >
<!ATTLIST Z         gel     CDATA   #FIXED  "z-pt"
gelid   NUMBER  #IMPLIED
>

<!ELEMENT Theta     - -   (#PCDATA)                                   >
<!ATTLIST Theta     gel     CDATA   #FIXED  "angle"
gelid   NUMBER  #IMPLIED                          >

<!ELEMENT Phi       - -   (#PCDATA)                                   >
<!ATTLIST Phi       gel     CDATA   #FIXED  "angle"
gelid   NUMBER  #IMPLIED                          >

<!ELEMENT Width     - -   (#PCDATA)                                   >
<!ATTLIST Width     gel     CDATA     #FIXED  "length"
gelid   NUMBER    #IMPLIED
units   CDATA     #IMPLIED                        >

<!ELEMENT Height    - -   (#PCDATA)                                   >
<!ATTLIST Height    gel     CDATA     #FIXED  "length"
gelid   NUMBER    #IMPLIED
units   CDATA     #IMPLIED                        >

<!ELEMENT Dash      - -   (#PCDATA)                                   >
<!ATTLIST Dash      gel     CDATA     #FIXED  "dash"
gelid   NUMBER    #IMPLIED
id      ID        #IMPLIED
>

<!ELEMENT Layer     - -   (#PCDATA)                                   >
<!ATTLIST Layer     gel     CDATA     #FIXED  "layer"
gelid   NUMBER    #IMPLIED
id      ID        #IMPLIED                        >

<!ELEMENT Color     - -   (#PCDATA)                                   >
<!ATTLIST Color     gel     CDATA     #FIXED  "color"
gelid   NUMBER    #IMPLIED
map     CDATA     #IMPLIED
style   (rgb | cymk | hls) rgb                    >

<!ELEMENT Base      - -   (#PCDATA)                                   >
<!ATTLIST Base      gel     CDATA     #FIXED  "angle"                 >

<!ELEMENT Tip       - -   (#PCDATA)                                   >
<!ATTLIST Tip       gel     CDATA     #FIXED  "angle"                 >

<!ELEMENT Arrow     - -   (Base, Tip, Length)                         >
<!ATTLIST Arrow     gel     CDATA  #FIXED  "arrow"
gelid   NUMBER #IMPLIED
filled  CDATA  #IMPLIED
style   CDATA  #IMPLIED
id      ID     #IMPLIED                          >

<!ELEMENT Pen       - -   (Width?, Color?, Dash?, Arrow?)            >
<!ATTLIST Pen       gel     CDATA  #FIXED  "pen"
gelid   NUMBER #IMPLIED
id      ID     #IMPLIED                          >

<!ELEMENT Pattern   - -   (#PCDATA)                                  >

<!ELEMENT Fill      - -   (Color, Color?, Angle?, Pattern?)          >
<!ATTLIST Fill      gel     CDATA  #FIXED  "fill"
gelid   NUMBER #IMPLIED
id      ID     #IMPLIED
style   CDATA  #IMPLIED                          >

<!--
Basic Defining Element Wrapper

This defining element wrapper allow all basic objects,
points, and references to other points to occur as needed to
construct a valid graphical object.
-->
<!ELEMENT DrawData  - -   ((%GelBasic; | %PointData)*)               >
<!ATTLIST DrawData  gel     CDATA  #FIXED  "geldef"                  >

<!--
Primitive Type:  Group

This type allows a collection of objects to be grouped together.
While the group may have an identity, it may only be referenced
by other elements in the current file.
-->
<!ELEMENT Group     - -   (DrawData, %Gels;)*                        >
<!ATTLIST Group     id      ID     #IMPLIED
gel     CDATA  #FIXED  "group"
gelid   NUMBER #IMPLIED
>

<!--
Primitive Type:  Text (Graphic Paragraph)

This object allows text data to be associated (and bounded by)
graphical objects placed on the canvas.
-->
<!ELEMENT TextData  - -   (((%PointData; | Rectangle) & Layer &
Fill & Pen)*)                              >
<!ATTLIST TextData  gel     CDATA  #FIXED "geldef"                   >

<!ELEMENT Text      - -   (TextData, (#PCDATA))                      >
<!ATTLIST Text      id      ID     #IMPLIED
gel     CDATA  #FIXED  "text"
gelid   NUMBER #IMPLIED
Font    CDATA  #IMPLIED
Weight  CDATA  #IMPLIED
Size    CDATA  #IMPLIED
>

<!--
Primitive Type:  Point

Simple primitive consisting of a reference to a discreet
coordinate within the given canvas. Points so defined can then
be referenced by any number of other objects within the canvas.
Different marker types and colors can be assigned to distinguish
one point from another.  Point data can be supplied in explicit
object form wher the X, Y, and Z (or R, T, P) components are
listed individually, or in implicit form where a coordinate set
is supplied that are taken as X, Y, Z (or R, T, P) respectively.
The coordinate set must be enclosed in curly brace notation
and be space or comma delimited.

Point Styles are: c  : Cartesian Coordiantes, i.e., X, Y, Z
cr : Relative Cartesian Coordinates
p  : Polar Coordinates,     i.e., R, T, P
pr : Relative Polar Coordinates
-->
<!ELEMENT Point     - -   ((#PCDATA | ((X, Y, Z?) |
(Radius, Theta, Phi?))),
Pen?, Layer?, (%GelPar;)*)                >
<!ATTLIST Point     id      ID     #IMPLIED
gel     CDATA  #FIXED  "point"
gelid   NUMBER  #IMPLIED
style   (c | p | cr | pr) c
marker  CDATA  #IMPLIED
>

<!--
Primitive Type:  Line

Typical line definition consists of a two or more
points that form a series of connected line segments.
Associated paragraph data will be positioned in the
geometric center of the line segment group unless otherwised
indicated in the paragraph.
-->
<!ELEMENT Line      - -   (DrawData, (%GelObjects;)*)                >
<!ATTLIST Line      id      ID     #IMPLIED
gel      CDATA  #FIXED  "line"
gelid      NUMBER  #IMPLIED
>

<!--
Primitive Type:  Connector

Typical connector definition consists of a control point
reference on two other objects. Optionally, either (or both)
control point reference can be replaced with a value of -1 and
substitute the x and y coordinate values of the relavent endpoint
location.
-->
<!ELEMENT ConnData  - -   ((%PointData;)*, Layer?, Pen?, Offset*)    >
<!ATTLIST ConnData  id      ID     #IMPLIED
gel      CDATA  #FIXED  "geldef"
gelid      NUMBER  #IMPLIED
>
<!ELEMENT Connector - -   (ConnData?)                                >
<!ATTLIST Connector id     ID     #IMPLIED
gel    CDATA  #FIXED  "conn"
gelid  NUMBER #IMPLIED
h1     NUMBER #IMPLIED
h2     NUMBER #IMPLIED
id1    NUMBER #IMPLIED
id2    NUMBER #IMPLIED
style  CDATA  #IMPLIED
>

<!--
Primitive Type:  Rectangle

A rectangle has three definition modes that can be used:

1) Two Point    : In this mode, the bounding box for the
rectangle is specified by two points indicating
the lower-left, and upper-right corners
respectively.
2) Diagonal Line: In this mode, the bounding box for the
rectangle is specified by reference to a line
that is drawn across the diagonal of the
desired rectangle. (The end-points of which
are the two points needed in definition mode 1.)
3) Width-Height-Center
: In this mode, the rectangle is positioned by the
center point, and its width and height values.

Optional Primitive Elements:

Angle  : Specifies the rotation angle for the rectangle.
Radius  : Specified the filet radius to use at the corners.
Length  : Specified the chamfer length to use at the corners.
P    : Paragraph data to be associated with this rectangle.
-->
<!ELEMENT Rectdata  - -   (((%PointData;,%PointData;) | Line |
(Length, Length, %PointData;)),
(%GelBasic;)*)                            >
<!ATTLIST RectData  id     ID     #IMPLIED
gel    CDATA  #FIXED  "geldef"
>

<!ELEMENT Rectangle - -   (RectData, (%GelObjects;)*)                >
<!ATTLIST Rectangle id     ID     #IMPLIED
gel    CDATA  #FIXED  "rectangle"
gelid  NUMBER #IMPLIED
Style  (1,2,3) 1
>
<!--
Primitive Type:  Ellipse

An ellipse has several definition modes that can be used:

1) Bounding Box : In this mode, the bounding box for the ellipse is
specified. The lengths of the elliptical axes as
well as the elliptical plane are derived.
2) Axes Reference : In this mode, the semi-major and semi-minor axes
are referenced respectively by a 2-segment line. The
elliptical plane is derived from plane on which the
lines are drawn.
3) Foci, Length : In this mode, the ellipse is defined by explicit
reference to two points and a length value. This
mode allows an ellipse to be defined by its
mathematical properties.
4) Line, Length : This definition mode is similar to mode 1, but
the foci are assumed to be the endpoints of the
two lines.
-->
<!ELEMENT EllipseData - - (%GelBasic; | %PointData; | Line |
Rectangle)*                               >
<!ATTLIST EllipseData id   ID     #IMPLIED
gel      CDATA  #FIXED  "geldef"               >
<!ELEMENT Ellipse    - -  (EllipseData, (%GelObjects;)*)             >
<!ATTLIST Ellipse   id     ID     #IMPLIED
gel    CDATA  #FIXED  "ellipse"
gelid  NUMBER #IMPLIED
Style  (1,2,3,4) 1
>
<!--
Primitive Type:  Arc

An arc has several definition modes that can be used:

1) Center, Radius : In this mode, the center and a radius are specified.
2) Center, Edge   : In this mode, the center of the circle and an edge
point are given (2-points or a line).
3) Three Point    : In this mode, three co-planar points define edge
coordinates for the circle.

Optional Primitive Elements:

Angle  : Begin Angle. (Zero Degrees is horizontal and
parallel to the X axis.)
Angle  : End Angle.
-->

<!ELEMENT ArcData    - -  (%GelBasic; | %PointData; | Line)*         >
<!ATTLIST ArcData   id     ID     #IMPLIED
gel    CDATA  #FIXED  "geldef"                   >

<!ELEMENT Arc        - -  (ArcData, (%GelObjects;))*                 >
<!ATTLIST Arc       id     ID     #IMPLIED
gel    CDATA  #FIXED  "arc"
gelid  NUMBER #IMPLIED
Style  (1,2,3) 1
>
<!--
Primitive Type:  Parabola

The extents of the parabola to be drawn will be defined by the end
points of the referenced line data.

-->
<!ELEMENT Parabola   - -  (DrawData, (%LineData;), (%GelObjects;)*)  >
<!ATTLIST Parabola  id     ID     #IMPLIED
gel    CDATA  #FIXED  "parabola"
gelid  NUMBER #IMPLIED
>

<!--
Primitive Type:  Spline

Typical spline definition consists of a three or more points that
form a series of connected line segments.  The degree attribute will
determine the amount of smoothing that will occur. Associated paragraph
data will be positioned in the geometric center of the line segment
group unless otherwised indicated in the paragraph.

Optional Primitive Elements:

LineData 0  : Tangent constraint for first line segment.
LineData 1  : Tangent constraint for last line segment.
-->
<!ELEMENT SplineData - -  ((%GelBasic; | %PointData;)*,
(Line, Line)?)                            >
<!ATTLIST SplineData id    ID     #IMPLIED
gel      CDATA  #FIXED  "geldef"                >

<!ELEMENT Spline     - -  (SplineData, (%GelPar;)*)                  >
<!ATTLIST Spline    id     ID     #IMPLIED
gel    CDATA  #FIXED  "spline"
gelid  NUMBER #IMPLIED
degree NUMBER #IMPLIED
>
<!--
Primitive Type:  Bezier

Typical spline definition consists of a three or more points that
form a series of connected line segments.  The degree attribute will
determine the amount of smoothing that will occur. Associated paragraph
data will be positioned in the geometric center of the line segment
group unless otherwised indicated in the paragraph.

Required Primitive Elements:

Four Points   : . (Bezier Curve)
-->
<!ELEMENT Curve      - -  (DrawData, (%GelObjects;)*)                >
<!ATTLIST Curve     id     ID     #IMPLIED
gel    CDATA  #FIXED  "bezier"
gelid  NUMBER #IMPLIED
>

<!ELEMENT Xref       - -  EMPTY                                      >
<!ATTLIST Xref       idref IDREF  #REQUIRED                          >

<!ELEMENT Symbol     - -  EMPTY                                      >
<!ATTLIST Symbol    gelref CDATA  #IMPLIED
gel    CDATA  #FIXED "symbol"
trans  CDATA  #IMPLIED
rotate CDATA  #IMPLIED
scale  CDATA  #IMPLIED
reference CDATA  #IMPLIED
>
<!ELEMENT Symdef     - -  (DrawData?, (%GelObjects;)*)               >
<!ATTLIST Symdef    id     ID     #IMPLIED
gel    CDATA  #FIXED "symdef"
ObjName CDATA #IMPLIED
Draw   (Yes | No) Yes
>

<!ELEMENT RasterData - -  (DrawData?, (%GelObjects;)*)               >
<!ATTLIST RasterData id    ID     #IMPLIED
gel   CDATA  #FIXED "raster"
type  CDATA  #IMPLIED
file  CDATA  #IMPLIED
>
<!-- End of DTD -->

Appendix 2 - Sample Graphic Document

The following image illustrates a few properties of the GEM language using a small, but complete, example of a graphic document.

Architecture associations are shown using the “gel” attribute. These associations are normally provided by information contained in the DTD and are therefore not necessary in the document. They are shown here on every object to improve readability.

<!DOCTYPE GraphicDTD PUBLIC "-//InfoSphere//DTD Graphic V3//EN" [
]><Canvas BGcolor="{255 255 255}" gel="canvas" xrange="0 400" yrange="0 400">
<Rectangle gel="rectangle">
<Rectdata gel="geldef">
<Point gel="point">{ 100.000, 150.000 }</Point>
<Point gel="point">{ 300.000, 250.000 }</Point>
<Fill gel="fill">
<Color gel="color">{ 0, 0, 255 }</Color>
</Fill>
</Rectdata>
</Rectangle>
<Ellipse gel="ellipse">
<EllipseData gel="geldef">
<Rectangle gel="rectangle">
<Rectdata gel="geldef">
<Point gel="point">{ 100.000, 100.000 }</Point>
<Point gel="point">{ 300.000, 200.000 }</Point>
</Rectdata>
</Rectangle>
<Angle gel="angle">0.000</Angle>
<Angle gel="angle">180.000</Angle>
</EllipseData>
</Ellipse>
<Ellipse gel="ellipse">
<EllipseData gel="geldef">
<Rectangle gel="rectangle">
<Rectdata gel="geldef">
<Point gel="point">{ 125.000, 150.000 }</Point>
<Point gel="point">{ 75.000, 250.000 }</Point>
<Angle gel="angle">90.000</Angle>
</Rectdata>
</Rectangle>
<Angle gel="angle">0.000</Angle>
<Angle gel="angle">180.000</Angle>
<Pen gel="pen">
<Color gel="color">{ 255, 0, 0 }</Color>
<Dash gel="dash">2</Dash>
</Pen>
<Fill gel="fill">
<Color gel="color">{ 0, 255, 0 }</Color>
</Fill>
</EllipseData>
</Ellipse>
</Canvas>

Appendix 3 - Three-Dimensional Experiments

InfoSphere has experimented with some three-dimensional capabilities of the GEM language. In these experiments, the graphic information was modeled in GEM and converted to VRML for display in the Cosmos plug-in.

The following table contains the architecture descriptions of the three-dimensional types utilized during our tests.

Experimental 3-D Types
Architecture	Defining Element Wrapper	Required Content for Valid Definition
box	Yes	Point, Length, Length, Length Interpreted as center, width, height, and depth.
cylinder	Yes	Line, Radius Interpreted as the longitudinal axis and the constant cylindrical radius.
sphere	Yes	Point, Radius Interpreted as the center and the uniform spherical radius.

The following example illustrates how the GEM language easily adapts to 3-D models:

<canvas xrange=”-500, 500" yrange=”-500, 500" zrange=”-500, 500">
<box>
<drawdata>
<point>{0.00, 0.00, 0.00}</point>
<width>100.00</width>
<height>50.00</height>
<depth>30.00</depth>
<fill>        <color>{0, 255, 0}</color>
</fill>
</drawdata>
</box>
<sphere>
<drawdata>
<point>{100.00, 100.00, 0.00}</point>
<radius>50.00</radius>
<fill>
<color>{255, 0, 0}</color>
</fill>
</drawdata>
</sphere>
<cylinder>
<drawdata>
<line>
<drawdata>
<point>{0.00, 0.00, 0.00}</point>
<point style=”pr”>{2.00, 45.00, 0.00}</point>
</drawdata>
</line>
<radius>20.00</radius>
<fill>
<color>{0, 0, 255}</color>
</fill>
</drawdata>
</cylinder>
</canvas>
#VRML V1.0 ascii

Separator  {
Separator {
Material {  diffuseColor 0.0 1.0 0.0
shininess 0.5 }
Transform {  scaleFactor 1.0 0.5 0.3 }
Cube { }
}
Separator {
Material {  diffuseColor 1.0 0.0 0.0
shininess 0.5 }
Translation {  translation  2.0  2.0  0.0 }
Sphere {  radius .5}
}
Separator {
Material {  diffuseColor 0.0 0.0 1.0
shininess 0.5 }
Transform {  scaleFactor 1.0 1.414 1.0
rotation 0 0 1 -.7853 }
Translation { translation 0.0 1.0 0.0 }
Cylinder { radius 0.2}
}
}

The above graphical data would be displayed by a VRML viewer as shown below:

Experimental 3-D Image

In an actual 3-D implementation, it is anticipated there will be a need for many more object types for shading, light sources, camera locations, complex rotations, etc. However, for evaluation purposes, the above example was simple to develop and clearly lends itself to easy interpretation for rendering. This, is consistent with the overall goal of the GEM language.


XML Query Language (XQL)		Table of contents		Indexes		Meta-analysis of clinical documents for principled markup of Medical Records