HOME | NEW | ABOUT PASSAGE | PRODUCTS AND SERVICES | TRAINING | PUBLICATIONS | SGML INFO | FEEDBACK
Eliot Kimber is a Senior SGML Consultant and HyTime Specialist for Passage Systems Inc. Before joining Passage Systems, Eliot worked at IBM, where he was a member of the ID Framework design team and one of the principle architects of the IBMIDDoc SGML application. Eliot is also a member of the SGML and HyTime standards committee. He is currently writing a book on HyTime as part of the Charles F. Goldfarb Series on Open Information Management, to be published by Prentice Hall Professional Technical Reference in the Spring of 1996.
Discuss why the SGML LINK feature is important, the role it plays in the standardization and interchange of document processing information. Also discusses the specific ways in which LINK can be used effectively. Proposes a simple convention for the use of LINK. Discusses the relationship between LINK and other style and transformation specification mechanisms, such as DSSSL.
LINK, DSSSL, style, transformation
The SGML LINK feature provides the ability to dynamically associate processing-specific information (i.e., "style") with SGML documents at parse time using syntax defined in ISO 8879. This association can be tied to the element hierarchy or associated with specific elements directly. LINK is not a replacement for application-specific style languages. Rather, LINK is intended to be an indirection mechanism that associates a general description of style, such as named styles, macro names, or generic presentation specifications, with application-specific style definitions (e.g., the expansions of macros, the styles named, or interpretations of generic presentation specifications).
Note: Note that the LINK feature has nothing to do with hyperlinking, at least as that term is generally used. The linking in this case is the link from elements in the input document type to elements in some result document type.
The LINK mechanism works by associating new attributes with elements in the source document ("link attributes"), and optionally, associating element types and attributes in a result document type with the elements in the source document. Link attributes associated with source elements are treated as though they had been specified in the document itself except that the names of LINK attributes may be the same as the names of attributes defined in the DTD.
The SGML standard defines three flavors of link, which differ according how explicit they are about the nature of the result document type. These three types are:
The association mechanism is defined through the use of "link rules", which are organized into "link sets". Each link rule associates an element in context with any link attributes and, for explicit link, the result element type and attributes. Link sets are organized into "link processes". A document may have one or more link processes associated with it, but only one can be active at a time. It is up to the processing application to determine which link process is active when parsing starts.
Link is important because it defines a standardized way to do hierarchical association of style to elements using SGML-defined mechanisms. For this reason, it serves as a bridge between the SGML parsing of a document and the processing done by specific processing systems.
As a bridge it provides a way to capture most of the style specification that is independent of specific processing technology. Specifically, LINK provides a way to capture when processing or presentation style needs to change or the nature of the change. For any given document type, the places within the document that presentation style changes generally remain constant for a particular presentation result regardless of how the result itself is specified. In other words, the places in the document that are decision points in the presentation are the same in every style sheet that gives the same style of presentation--all that differs are the details of how the specific style sheets work. LINK provides a mechanism for separating the decision points from the detailed presentation specifications.
This separation makes it possible to re-use the definition of the decision points for different presentation systems with different style specification mechanisms. Most of the hard work of style specification goes into understanding where the decision points are, what the unique contexts are that must be accounted for. Once that understanding has been represented in a machine-readable form, you should be able to re-use it for different applications. LINK provides that.
Because it separates out the decision making from the presentation specification, LINK can simplify application-specific processing by letting the SGML parser make some or all of the contextual choices. This will tend, for example, to make online presentation systems more efficient and their style sheets simpler.
LINK makes it easier to adapt new tools and presentations to documents by reducing the amount of new style definition work that needs to be done.
I want support for simple link and implicit link. I do not want explicit link.
Explicit link is not sufficient to do many SGML-to-SGML mappings. If your only interest is capturing the points at which style must change, then you only need simple and implicit link. The task that explicit link attempted to address is better solved by more robust mechanisms such as the DSSSL transformation language or proprietary transformation systems such as Exoterica's Omnimark language or the CoST tools.
For simple link, I want to use it simply to associate a style-sheet name with a document. This would provide a general, standard, existing mechanism for associating style sheets with documents, replacing the various application-specific conventions in place today. A typical example might look something like this:
<!DOCTYPE MyDoc [ <!ELEMENT MyDoc - O (#PCDATA) > <!NOTATION panorama PUBLIC "-//Synex A.G.//NOTATION Panorama Style Definition//EN"> <!NOTATION dynatext PUBLIC "-//Electronic Book Technologies//NOTATION DynaText Style Definition//EN"> ]> <!LINKTYPE panostyl #SIMPLE #IMPLIED [ <!ENTITY mainview SYSTEM "mainview.ssh" NDATA panorama> <!ATTLIST MyDoc style ENTITY #FIXED "mainview"> ]> <MyDoc><!-- Parser will see "style=mainview" as one of the attributes of the MyDoc element -->
How the link attribute information is conveyed to applications will vary. Here is the result of processing the above document with NSGMLS:
p-//Synex A.G.//NOTATION Panorama Style Definition//EN NPANORAMA smainview.ssh f<OSFILE NOZAPEOF ASIS>mainview.ssh Emainview NDATA PANORAMA aPANORAMA STYLE ENTITY mainview (MYDOC )MYDOC C
The first five lines are the data about the entity named in the link attribute (the Panorama style sheet). The next line, beginning with "aPANORAMA", is the record for the link attribute. NSGMLS prefixes the link attribute data with the name of the active link process ("panorama", in this case).
To support different presentation systems, you could add additional LPDs:
<!DOCTYPE MyDoc [ <!ELEMENT MyDoc - O (#PCDATA) > <!NOTATION panorama PUBLIC "-//Synex A.G.//NOTATION Panorama Style Definition//EN"> <!NOTATION dynatext PUBLIC "-//Electronic Book Technologies//NOTATION DynaText Style Definition//EN"> ]> <!-- Set Panorama Style: --> <!LINKTYPE panorama #SIMPLE #IMPLIED [ <!ENTITY mainview SYSTEM "mainview.ssh" NDATA panorama> <!ATTLIST MyDoc style ENTITY #FIXED "mainview"> ]> <!-- Set DynaText Style: --> <!LINKTYPE dynatext #SIMPLE #IMPLIED [ <!ENTITY fulltext SYSTEM "fulltext.v" NDATA dynatext> <!ATTLIST MyDoc style ENTITY #FIXED "fulltext"> ]> <MyDoc>
When the link process "dynatext" is made the active LPD, NSGMLS gives this result:
p-//Electronic Book Technologies//NOTATION DynaText Style Definition//EN NDYNATEXT sfulltext.v f<OSFILE NOZAPEOF ASIS>fulltext.v Efulltext NDATA DYNATEXT aDYNATEXT STYLE ENTITY fulltext (MYDOC )MYDOC C
For implicit link, I want to associate either a single style keyword (named style), representing a defined set of style parameters, or a set of style parameters (font, indention, etc.) that are generic enough to be generally understandable by most presentation systems.
For implicit link there is one aspect of LINK processing that 8879 leaves up to the processing application, namely the mechanism for selecting among multiple link rules for the same element. The LINK mechanism allows multiple link rules for the same element and leaves it up to applications to decide which one to use, presumably based on the the value of one or more attributes of the element in question.
To solve this problem, I propose the following convention for standardizing the selection mechanism:
These conventions make it possible for LINK rules to be associated with elements in context using more than the hierarchical mechanism by LINK. It would, in fact, be possible to have a single link set where all contextual qualification was done through the selector attribute, although in practice it would probably make more sense to combine LINK-defined hierarchical qualifications with more complex selection criteria, such as attribute values or the presence or absence of non-ancestor elements.
LINK does not replace DSSSL. Rather, LINK works with DSSSL, letting authors decide how much of the style work to do with LINK and how much to do with DSSSL. Because LINK does not address the problem of actually defining presentation, you still need DSSSL as a standard style presentation mechanism.
In addition, not all applications will support DSSSL, so there is still a need for a neutral and standardized mechanism for isolating some of the style specification from application-specific style mechanisms.
HOME | NEW | ABOUT PASSAGE | PRODUCTS AND SERVICES | TRAINING | PUBLICATIONS | SGML INFO | FEEDBACK