Presenting HyTime Documents with HTML Lloyd Rutledge Distributed Multimedia Systems Laboratory Computer Science Department University of Massachusetts Lowell
[email protected]
Abstract: Due to the wide-spread use of the WWW, many institutions are using HTML to encode their documents for hypertext presentation. However, HTML is not always suitable for long-term document storage. Hypermedia/Time-based Structuring Language (HyTime) is designed for the long-term and presentation-independent storage of hypertext documents. Because of the close relationship both HTML and HyTime have with Standard Generalized Markup Language (SGML), HyTime-encoded documents can easily be translated into HTML. This paper discusses the issues involved in such translations.
Introduction HTML has become widely used as a format for hypermedia documents. It specifies a model for text documents with hypertext links and non-text media objects. While HTML has served the needs of current hypertextual usage, it falls short of answering the anticipated demands of hypermedia environments. In particular, HTML enforces a single document that is closely tied to its presentation. As such, HTML is an inappropriate format for the long-term storage of hypertext documents that may be presented by means other than HTML browsers. Standard Generalized Markup Language (SGML) [Goldfarb 91] and Hypermedia/Time-based Structuring Language (HyTime) [ISO 92] encode the presentation-independent structure of hypermedia documents. They also specific, using Document Type Definitions (DTDs), the general document structures of classes to which individual documents can conform. SGML defines a set of fundamental primitives for defining documents and document models. HyTime extends SGML by defining composites that represent hypermedia structure. HyTime constructs locate document objects, establish relations between objects, and schedule the placement of objects using measured coordinates. HTML is defined as a single SGML DTD. The fact that HTML and HyTime share a common foundation in SGML facilitates the conversion between them. This paper describes three categories of conversion: hyperlinking, locating, and scheduling. Hyperlinking is establishing relationships between document portions. Locating is defining document portions so they can be referred to individually. Scheduling is defining numeric relationships between document portions. We first discuss the issues in converting HyTime documents into HTML for presentation. Background information on HyTime and SGML are provided. The HyTime and HTML constructs involved in conversion are described. The potential conversions between HyTime constructs and corresponding HTML constructs are discussed. Finally, related work is described and a summary provided.
Background SGML Standard Generalized Markup Language (SGML) is an international standard for defining the textual encoding of document structure and content. It delimits the text content into containers called elements. Elements can contain other elements, text, or both. Each element has a generic identifier (GI) that states the element’s type name. SGML defines attributes that are associated with and describe elements. Each attribute has a name and a value. Two particularly useful attribute types are the unique identifier (ID) and the unique identifier reference
(IDREF). An ID attribute gives its element a unique name within the document. An IDREF attribute has as its value the ID of some other element in the document, thus representing a reference to the element. The third primary construct of SGML is the entity. One of the most important uses of the entity is to enable the inclusion of external files in any format, even non-text, in a document element. Together these constructs provide the hierarchical structure of a document, descriptive information about portions of the document, and the inclusion in the document of external resources and information. A DTD defines a set of element types that can be used in conforming SGML documents. It also defines the set of attributes that can be used with each element type. HyTime Hypermedia/Time-based Structuring Language (HyTime) is an international standard for defining the SGML encoding of hypermedia document structure. HyTime defines a set of primitives, called architectural forms, that represent the hypermedia aspects of a document. These aspects include multi-directional and multiply anchored hyperlinking, descriptive, flexible, and powerful document object locating, and the scheduled placement of document objects along measured axes. HyTime extends SGML by defining how instances of these architectural forms are built from SGML constructs. An SGML element is recognized as an instance of a form if an HyTime architectural form attribute is assigned to it. Usually this attribute’s name is “HyTime”. Its value is the name of the form to which the element conforms. When an element is a form instance, particular HyTime attributes can be assigned to it. These attributes provide information about the hypermedia nature of that element. Elements conforming to forms are called HyTime elements. As an open document architecture, HyTime does not enforce a single document model. HyTime does not specify a single DTD but instead defines constructs that can exist in documents of different DTDs. While such DTDs define separate models, their documents can all share HyTime definitions that are uniformly recognized. HyTime Hyperlinking Constructs Some HyTime elements specify hyperlink structures. Such elements reference groups of document objects and describe a relation that exists between them. The contextual link (clink) architectural form establishes that a simple hyperlink exists between two document objects. One of these objects is the clink element itself. The other object is specified with an attribute named linkend. The independent link (ilink) architectural form provides a more complex definition for hyperlinks than the clink. An ilink element can, for example, link together more than two objects. It can also restrict the direction of traversal between objects. Role names can be defined for an ilink’s link ends. When used in conjunction with certain location addressing constructs, an ilink can define a cascading sequence of hyperlinks that can be traversed one at time or all at once. HyTime Locating Constructs Some HyTime elements specify location addresses. These associate an SGML ID not with a single element but potentially with more complexly defined document objects. When an IDREF is made to a location address element, the reference is not to the element with the ID but instead to the document object the element’s address locates. The notation location (notloc) architectural form uses a string in a particular non-HyTime notation to address a document object.The name space location (nameloc) and name list specification (nmlist) architectural forms enable the location of objects in external SGML documents using their IDs or entity names. SGML by itself allows elements and entities in the same document to be reference by their ID or entity name. HyTime Scheduling Constructs Some HyTime elements can define measured coordinate systems and the placement of document objects within those systems. A timeline for presentation could be such a coordinate system. HyTime could then specify particular document portions as occurring at specified times. Such a coordinate system could also map the areas of a display screen. Images could be specified as document objects that are displayed at particular locations on the screen. The event schedule (evsched) architectural form specifies a collection of objects with measured
placements in one instance of a coordinate system. An event schedule could represent a single screen display or one possible timeline of a multimedia presentation. The event architectural form represents the placement of a single object in an event schedule. It assigns one set of coordinates to that object. The contents of the event element define the object being placed in the schedule. The extent specification (exspec) architectural form is used by an event element to define its coordinates. HTML HTML Hyperlinking Constructs The interactive behavior of HTML documents is defined by HTML anchor (a) elements and their hypertext reference (href) attributes. The contents of such elements are considered “hotspots”. Their selection by the user causes another document or document portion to be displayed. This relationship between a hotspot and the display its selection creates is typical of hyperlinks. Such links in HTML are one-directional: selecting the hotspot brings up another document segment, but that segment does not necessarily act as a hotspot back to the original location. Also, each anchor can only link to one other document object. HTML Locating Constructs Although HTML uses SGML, it uses neither entities to reference external files nor SGML IDs to reference portions of the same document. There are attributes in HTML, however, that use HTML-specific schemes for such references. These attributes can have their values in Uniform Resource Locator (URL) notation. This notation specifies the locations of document objects on the WWW. Such an attribute can also have as its value the pathname of a file relative to the current document’s pathname on its file system. In either case, the located file is considered to be the object referenced. One such attribute is the source (src) attribute of the in-line image (img) element type. An img element specifies the occurrence of an in-line image within the display of a text document. The src attribute locates the file containing that image. The href attribute of the anchor element also performs such a reference. This attribute specifies what is presented when the element content is selected. A file located by this attribute can be of any medium type, as long as the system on which it is to be presented is configured to present that medium type. In addition to the value possibilities described above, the href attribute can also reference a portion of an HTML document. Such a portion would be defined as the contents of an anchor element with its name attribute assigned. If the anchor tag specifies a name attribute, then other anchor href attributes can use that attribute’s value to specify this anchor as a link end. An anchor’s name would appear after a ‘#’ character in an href attribute. The ‘#’ and anchor name could appear by themselves to indicate the destination of this link is a named anchor in the same document. Putting a file pathname or URL specification before the ‘#’ would locate the named anchor in the specified HTML document file. HTML Scheduling Constructs There are not many scheduling-related semantics in HTML. HTML defines no time-lines for presentation and no measured coordinate systems for screen displays. One HTML construct that suggests scheduling semantics is the image map. An image map is an img element that is defined as a hotspot (that is, as the content of an anchor element with its href attribute assigned) and has its ismapattribute assigned. Different portions of an image map can be clicked on to access different objects. The URL accessed by clicking on an image map is the href attribute value followed by a ‘?’ character and two numbers giving the coordinates of the image where the mouse click occurred. The server specified in the URL can then process the address with the coordinate suffix to determine the appropriate document object to return.
Converting the Constructs It is impractical to devise a scheme for converting all SGML or HyTime documents to HTML. The DTD of a document will typically define a model with components that have semantics particular to that document set. Most of the translation of such components to HTML code needs to be done for each document model individually. However, there are some HyTime constructs with semantics that are general enough to suggest a common HTML interpretation across all document models. Some of these constructs were introduced earlier in this paper. In this section, we discuss how these HyTime constructs could be interpreted into HTML.
Converting Hyperlinking Constructs Although HyTime-defined hyperlinks are not strictly navigational in nature, navigational relationships are frequently encoded as hyperlinks. Given this association between hyperlinks and navigation, we discuss converting HyTime hyperlinks to HTML-defined hotspots. An href anchor defines only that one document object, when selected, leads to the display of one other. Defining traversability in the other direction would require an additional anchor element, or at least an additional href attribute. Each document object can be the start of only one link. HyTime, on the other hand, allows for the defining of very complex hyperlink structures. HyTime links can be bi-directional and involve more than two anchors. Further, allowable directions of traversal through a link can be restricted. Since HyTime hyperlinks are complex than HTML anchors, an individual HyTime link may need conversion to a composite of HTML anchors. Part of converting HyTime hyperlinks is the conversion of the IDREF attributes defining the link ends, as discussed below in the section titled “Converting Locating Constructs”. A clink defines two anchors for a link. One anchor is the clink element itself and its contents. The other is specified by an IDREF attribute named linkend. A clink element could be represented in an HTML document by an anchor element with its href attribute assigned to locate the object the HyTime linkend attribute located. This anchor element would have most of the hyperlinking semantics of its source clink. However, since clinks can potentially be bi-directional, it may be appropriate to name the HTML anchor and put a href anchor around the located object reference back to the link’s starting point. Below is an example of some HyTime clink code and a possible HTML conversion [Fig. 1]. An ilink element can define a hyperlink with more than two link ends. Since an HTML anchor can have only two link ends, it would take more than one HTML anchor element to present such an ilink. Such a conversion could consist of defining for each HyTime link end a collection of HTML anchors. Each anchor for a link end would access one of the other HyTime link ends. As such, each traversal allowed by the HyTime code from one linkend to another would be encoded as a distinct HTML anchor. Each of these HTML anchors would be displayed as a particular string or piece of text. This text is the content the each anchor. If the source ilink has anchor roles defined for it by HyTime, each resulting HTML anchor could contain the text making up this anchor role. As
Figure 1: A HyTime clink and its HTML conversion
such, the user would see highlighted as hotspots the names of the various roles the anchors in the link has. The user can then select the appropriate role name. A HyTime ilink element can have traversal direction restrictions placed on its anchors. Such restrictions could be reflected in the HTML anchors that are generated for an ilink. As described in the previous section, a separate HTML anchor can be defined for each possible traversal between a pair of link ends. Any such traversal that is not allowed due to a traversal direction restriction would not have its corresponding HTML anchor generated. As such, that traversal would not be enabled by HTML processing.
Converting Locating Constructs Since HTML does not use any IDs or IDREFs, any use of unique identifier referencing in a HyTime document needs to either be eliminated or converted to an HTML-defined reference. This is true even if no HyTime location address elements are used as part of the reference. If the original reference is semantically appropriate for representation as an HTML referencing attribute, then such a conversion can take place. Such HTML attributes include the src attribute of the img element and the href attribute of the anchor element. As such, references to image files to display or to link ends of hyperlinks may be appropriate for this translation. The converting of an SGML/HyTime reference consists of two parts. First, the start of the reference must be converted. This would typically consist of transforming an IDREF attribute into an HTML referencing attribute such as href or src. The value of the attribute would also have to be changed from the unique identifier to an HTML equivalent. This equivalent could be either a URL, a filename, or, in the case of href attributes, a named anchor. The second part of converting an SGML/HyTime reference is encoding the end of the reference. The reference destination must be represented so that it can be specified with HTML referencing attribute. If the destination is a file, then a URL string or file system pathname can reference it and no changes are necessary. If the destination is a portion of a file, then an HTML equivalent of that portion must be encoded so that it is or is contained in an HTML named anchor. As a named anchor, it can be referenced by the href attribute. If a HyTime linkend attribute specifies an element as an anchor by referring directly to its ID, then its HTML translation could involve the creation of a named anchor. The semantics of the hyperlink would be encoded in HTML using the techniques for converting hyperlinking constructs described earlier. The destination of the reference would be encoded so that it was contained in a named anchor, perhaps given the same name as the original ID (assuming it was not already used as a name in that document). The href attribute for that link end would then reference this named anchor. As such, its value would be the name itself preceded by a ‘#’. An example of the conversion of an IDREF to a named anchor is provided above [Fig. 1]. The World Wide Web has made the use of URL notation wide-spread. The use of URL notation in HyTime and SGML documents in general has been proposed [Kimber 93]. This approach involves using SGML code to define a notation named “URL”, and then defining a HyTime notloc element type as containing a string in that notation. As such, a HyTime engine would recognize IDREFs to these notloc elements as references to the files located by the URL strings they contain. IDREF attributes to such notloc elements in HyTime documents could be converted to an HTML attribute whose value is the notloc’s URL contents.
Converting Scheduling Constructs In earlier work, we have created a HyTime-defined document set for use with a kiosk-style multimedia presentation system [Buford et al. 94]. This document set and its application is called Hypermedia Presentation (HMP). Each HMP display has areas that are hotspots. Clicking on one hotspot causes another screen display to appear. These screen displays and their navigational nature are defined with HyTime scheduling and hyperlinking constructs. Screen displays are represented as an event schedules. Hotspots are defined as events containing clinks. This specifies that the areas in the schedule represented by these events are, in some sense, “hot”. Each clink specifies as its other anchor the screen display event schedule to be shown next.
We have extended HMP so that these screen displays are shown on the WWW in HTML documents as image maps [DMSL 95]. As with the original application, clicking on a portion of the image that is a hotspot causes a particular new image to appear. The image is included in an HTML document as an in-line image. The fact that the image has hotspots is represented by its occurrence in an href anchor element. The ismap attribute indicates that selecting different portions of the image accesses different document objects. The coordinates of a selection are returned to the HMP http server for processing. The server then determines what hotspot event the selection occurs in and then returns the image map for the display that selection links to.
Related Work At the Second World Wide Web Conference, Eric Freese discussed the presentation of SGML documents in general with HTML [Freese 94]. In previous work we described some possibilities for encoding HTML documents using HyTime [Rutledge et al. 95]. Other possibilities for such an encoding have been described as well [DeRose & Durand 94].
Summary HTML is widely used for the presentation of hypertext documents but is not an appropriate format for the longterm storage of documents presented in a variety of circumstances. HyTime, with SGML, is better suited as such a format because it enables the defining of documents in terms of their presentation-independent structure. HyTime documents can be presented by converting them to HTML for processing by HTML browsers. This conversion is facilitated by both HTML and HyTime being defined using SGML. This paper approaches its consideration of the translation from HyTime to HTML by examining semantic overlaps between constructs of the two languages. HyTime hyperlinking constructs can be converted to patterns of HTML anchor elements with href attributes. HyTime location addressing constructs used in conjunction with hyperlinks can be translated into HTML anchor elements with name attributes. Finally, scheduling constructs used in conjunction with hyperlinks can be translated into HTML img elements with the ismap attribute set.
References [Buford et al. 94] Buford, John F., Rutledge, Lloyd, Rutledge, John L., and Keskin, Can, “HyOctane: A HyTime Engine for an MMIS”, Multimedia Systems, vol. 1, no. 4, Springer International, February 1994. [DeRose & Durand 94] DeRose, Steve J., and Durand, David G., Making Hypermedia Work: A User’s Guide to HyTime, Kluwer Press, 1994. [DMSL 95] Distributed Multimedia Systems Laboratory, DMSL Hypermedia Presentation (HMP) Page, http:// dmsl.cs.uml.edu/hmp.html, 1995. [Freese 94] Freese, Eric D., “The Transformation of SGML Documents for Presentation on the World Wide Web”, Proceedings of The Second World Wide Web Conference 94: Mosaic and the Web, October 1994 [Goldfarb 91] Goldfarb, Charles F., The SGML Handbook, Oxford University Press, 1991. [ISO 92] International Standards Organization, Hypermedia/Time-based Structuring Language (HyTime), ISO/IEC IS 10744, April 1992. [Kimber 93] Kimber, W. Elliot, “HTML DTD and HyTime”, post to internet newsgroup comp.text.sgml, May, 1993. [Rutledge et al. 95] Rutledge, Lloyd, Buford, John F., and Rutledge, John L., “Applying HyTime to HTML”, Proceedings of IASTED/ISMM Distributed Multimedia Systems and Applications, August 1995.
