SGML Extended Facilities and HyTime Two   Table of contents   Indexes   Style Concepts
 
 

An Implementation design of XLL as a subset of HyTime
 
Masatomo   Goto
  Researcher
  Fujitsu Laboratories Ltd.
Information Service Architecture Labs. 64 Nishiwaki Ohkubocho
Akashi   Hyogo  Japan  674 8555
Phone: +81 78 934 8249
Fax: +81 78 934 3312
Email: gotou@flab.fujitsu.co.jp Web: www.fujitsu.co.jp
 
Biographical notice:
 
Masatomo Goto
 
Masatomo Goto had been implemented script engine for a text editor which was planed to extend a SGML editor. After that, from the end of 1995, he has been belonging to HyBrick development team at Fujitsu laboratories ltd. and rese arching SGML, HyTime, XML and XLL. He implemented a XLL engine this time, and is now designing new architecture using it's engine.
 
HyBrick is a SGML/XML document browser using DSSSL style sheet. HyBrick is now distributed as a FREEWARE. HyBrick is demonstrated at WWW6, the 4th HyTime conference and SGML/XML '97. He gave a speech and demonstrated HyBrick at the 4th International HyTime conference.
 
ABSTRACT:
 HyTime 
 XLL 
 
To provide a useful document management system having a facility to process link representations, we have already developed a document browser called HyBrick and intended to append the facility to process the link representat ions to this HyBrick. We selected XLL as the link representation. We consider that in the future synchronization of objects and representation of a space will also become necessary and that the XLL specification is nearly equal to the linkin g part of HyTime specification. So the new XLL engine is designed in line with the HyTime standard to be easily extended to HyTime. This paper gives an implementation design of that XLL engine, and also describes one application design using this engine.
 
 

1. Introduction
 
This paper describes an implementation design of an XLL engine, which is based on HyTime, and also describes one application design using this engine.
 
With the appearance of the World Wide Web, the concept of structured documents and hyperlinking have spread worldwide and become commonplace. However, HTML, which is the markup language used in the WWW system, is not actually a structu red language and its linking facility does not have enough link representations.
 
In terms of structuring, HTML is not a complete language: style information can be specified in the markup directly, and the document type is fixed. Although there is a markup language called SGML (Standard Generalized Markup Language) as the international standard , SGML is too big and complicated to master and is not convenient to use on the WWW system. The XML (eXtensible Markup Language) specification , which is a structural language designed to work on the WWW system, was thus proposed and is now quickly spreading in various fields.
 
As for Hyperlinking, the HTML link facility only associates the content of a linking element with an object directed by its attribute. For this reason, more sophisticated link facilities (such as making a link from another document, ma king a link among more than three objects and so on) that are needed to represent various kinds of relationship cannot be provided. Although there is the HyTime standard which can represent those various links and can also represent synchronization of objects and a space, HyTime is resource intensive. The XLL (eXtensible Linking Language) specification , which is still being drafted by W3C, is a hyperlinking language which works on XML.
 
The main purpose of our research is to provide a useful document management system having a facility to process link representations. We have already developed a document browser called HyBrick and intended to append the facility to pr ocess the link representations to this HyBrick. We selected XLL as the link representation and designed an XLL processor as the engine. We consider that in the future synchronization of objects and representation of a space will also become necessary and that the XLL specification is nearly equal to the linking part of HyTime specification. So the new XLL engine is designed in line with the HyTime standard to be easily extended to HyTime.
 
As the result of the designing XLL engine like a HyTime processor, this engine also works even on the SGML system. In other words, by treating XLL information as architecture on the SGML, SGML documents, which include XLL representatio ns, are manipulated without losing propriety.
 
introduces the design policy of the XLL engine and also shows how this XLL engine is associated with HyTime. introduces an application design using the newly constructed XLL engine, such that the engine and these link facilities are effective for XML and also SGML. Finally, draws conclusions about this XLL engine design and discusses future plans.
 
 

2. XLL engine design
 
 

2.1. Design policy
 
eXtensible Linking Language (XLL) enables an XML document to represent various kinds of hyperlink which are more sophisticated than HTML's "A" link. It provides facilities like multi-directional links, links among more than three objec ts, constructing links from another document and so on.
 AFDR 
 
In designing this XLL processing engine (XLL engine), we focus on the generality and efficiency of an application development process. Therefore, the engine should be a module and not embedded in an application d irectly. Moreover, to extend this XLL engine to the HyTime engine easily, this engine should be designed as an XLL architecture along with AFDR like HyTime.
 
AFDR (Architectural Form Definition Requirement) which is described in the annex of the HyTime 2nd edition , defines how to construct an architecture in the SGML document.
 
shows how to process XLL as the architecture. First, a grove which is one of the tree representations of SGML/XML documents defined by the HyTime 2nd edition, is generated from the SGML/XML document by a parser and a grove g enerator. Then the architecture engine constructs its architecture grove from those SGML/XML groves. Finally, through accessing those groves an application manipulates those documents and included architecture.

 
Fig. 2.1 XLL architecture processing

 
 DSSSL 
 
In addition to the SGML and HyTime standards, there is the DSSSL (Document Style Semantics and Specification Language) standard that uses grove to represent a document. Like these, in the field of SGML, all data representations of a document are grove, so the XLL engine also can be used in this field if the engine is designed to use grove as the data representation. Further, it is convenient that XPointer defined in the curr ent XLL draft, which is a query for addressing a position in a document, uses grove to resolve the query.
 Addressing 
 
XPointer is an addressing language used to point to a position in a document. If XPointer is described in a link to address a position, any part of a document (offcourse, one character in some CDATA) can be pointed to, although HTML's link can only point to a whole document or a specified element having special attributes.
 
shows the construction of an application including this XLL engine.

 
Fig. 2.2 An application construction

 
 
In the architecture processing described above, the XLL engine generates an architecture grove from the information represented in the document (i.e. SGML grove) through a parser and a grove manager, then communicates with an applicati on using its architecture grove and original SGML groves.
 
 

2.2. Construction of XLL engine
 
This section describes the construction of the XLL engine.
 
shows the construction of the XLL engine.

 
Fig. 2.3 XLL engine construction

 
 
This engine can be separated into three parts.
XML-Link module
 
This module creates an XLL architecture grove by extracting XLL information from SGML/XML groves. All application APIs are given from the module.
XML-ATTRIBUTE module
 
This module creates and stores maps between default attribute names and newly specified attribute names. This module is only called by the XML-Link module.
XPointer module
 
This module resolves an XPointer term written in HREF attribute, and searches for a corresponding node in a document. This module is called by the XML-Link module to create an architecture grove or define a node to traverse. (The word "traverse" means traversing between objects which are connected by an XLL's Link.)
 
The XPointer module is also designed to provide an interface outside the engine for further independent use of the addressing facility.
 
 

2.3. XLL Property Set
 Property Set 
 
As described in the SGML extended facilities in the annex of the HyTime 2nd edition, a grove is created according to an appropriate property set defined according to PSDR (Property Set Definition Requirem ent: definitions of how to define a property set) .
 
A property set is a data representation needed to construct a grove. Most part of a property set is constructed by "Property: a type of data representation which a node in a grove has" and "Class: a type of a node". They are categorize d as "Module".
 
To create an XLL architecture grove, a property set defined for the XLL should be newly created. It also needs to be designed to conform to the HyTime property set for further extension to HyTime. Therefore, the XLL property set is des igned by referencing some parts of the HyTime property set which are related to the XLL.
1. Bounded object set module
 
This module includes properties and a class, which represent HyTime BOS. From this module, a class and properties representing an extended link group are defined.
2. HyTime document module
 
This module includes properties and a class, which represent the HyTime document. From this module, properties and a class which represent the XLL document (means document including XLL information the same as the HyTime document defined by the HyTime standard) are defined.
3. Effective SGML document module
 
This module includes a property, which represents a pointer to the original SGML grove's node. From this module, a property which has the same meaning as HyTime is defined.
4. Hyperlink module
 
This module includes properties and classes, which represent all links consistently. From this module, properties and classes which represent two links (SIMPLE and EXTENDED) consistently are defined.
5. Hyperlink type module
 
This module includes properties and a class, which represent the hyperlink type. From this module, a property which represents a type of Link is defined.
6. Location address targets module
 
This module includes properties and a class, which represent referenced and referencing information created by resolving the location address. From this module, properties and a class which represent referenced and referencing inf ormation are created by resolving XPointer.
7. Location address path module
 
This module includes properties and a class, which represent the HyTime Location address. From this module, properties and a class which represent HREF attribute as the location address are defined.
 
The following list shows newly created classes for the XLL property set. In each explanation, properties, which are specified in each class, are also shown with their type.
HyperXmlDocument (HyperXmlDoc)
 
Corresponds to the HyperDocument class. Grove root of XLL. This class has reftargs (subnodelist to ReferenceTargets), group (subnodelist to GroupDocument), xmldocs (subnodelist to XmlDocument), hubdoc (irefnode to XmlDocument whic h is hub document) and resobj (subnodelist to ResourceObject) properties.
GroupDocument (GrpDoc)
 
Corresponds to the BosMember class. Representation of extended link group. This class has steps (integer) and href (subnode to href) properties.
XmlDocument (XmlDoc)
 
Corresponds to HyperDocument class. Representation of XML-Link document. This class has hub (bool), sgmldoc (urefnode to a SGML grove's node) and content (subnodelist to XmlLink) properties.
ResourceObject (ResObj)
 
Corresponds to the AnchorObject class. Representation of resource which can start traversal. This class has object (urefnode to a SGML grove's node) and locators (irefnodelist to locator) properties.
XmlLink
 
Corresponds to the HyperLink class. Representation of XML-Link element. This class has typename (string), xmllktp (enum), definition (urefnode to a SGML grove's node) and locators (subnodelist to locator) properties.
Locator
 
Corresponds to the anchor class. Representation of locator information. This class has ancrole (string), title (string), role (string), show (string), actuate (string) , href (subnode to Href) and object (UREFnode to a SGML grove' s node) properties.
ReferenceTargets (RefTargs)
 
Corresponds to the ReferenceTargets class. Representation of reference. This class has ref (urefnode to a SGML grove's node), targets (urefnodelist to SGML grove's nodes) and href (subnode to Href) properties.
Href
 
Corresponds to LocationAddress class. Representation of Href data as Location address. This class has url (string), xpointer (string) and connectortype (enum) properties.
 
is a graph representation, which shows relation among this newly created classes and properties of the XLL property set.

 
Fig. 2.4 Graph representation of the XLL property set

 
 
All collection of these definitions is the XLL property set along with HyTime property set, and XLL architecture grove is constructed by referencing this XLL property set.
 
 

3. An application example using the XLL engine
 
 

3.1. Application API
 
All information needed in an application to represent links is stored in a constructed architecture grove (XLL grove), so an application can get that information easily by accessing that XLL grove. In addition, following four methods c an be used to give essential or additional facilities to the engine.
1. Grove Construction Method
 
Deletes the current XLL grove if it exists, then creates a new XLL grove.
2. Judging SGML/XML Node Method
 
Checks whether the given SGML/XML node is a resource of a link or not.
3. Getting Locator Information Method
 
Gets the Locator Node of the XLL grove which is appropriate to the given SGML/XML node if that node is a resource.
4. Traverse Link Method
 
Traverses to the node described in the given Locator node. This method returns the appropriate SGML/XML node if that node is in the XLL hyper grove. Otherwise, this method parses the document and appends it to the XLL grove then returns the traversed node.
 
By using these API, applications are able to manipulate link representations easily; it is an application which defines the link action (treat it as some kind of special facility, or represents links just like HTML links and so on) by accessing the XLL grove and SGML/XML groves.
 
That is, the hypergrove space - the space in which there are a plural number of SGML/XML groves and they are all linked by XLL grove - is constructed. Then an application creates a temporary document from that space and views it like H yTime processing.
 
 

3.2. An application example using this link engine
 
We designed a document browser that gives the annotation facility as a sample application using the XLL engine. The memorandum to a viewed document can be shown like a PostIt on the paper. Following is an overview of this application.
 
For the document browser, we use HyBrick. HyBrick is an SGML/XML document browser using DSSSL style sheet.

 
Fig. 3.1 Application Image

 
 
This application shows several use of the XLL link engine.
 
[1] Not only viewed documents but also memorandums can be the XML document, and both documents need not have a XLL information; one another document which includes XLL information is created and enables traversal between resources in these documents. Sample documents are like following picture.

 
Fig. 3.2 Example of documents

 
 
[2] To implement this annotation facility, the application uses three kinds of XLL features, which are not included in the HTML link facilities, like:
1. Out-of-line link:
 
Facility to construct a link without including it's own content as a resource
2. Multi-directional link:
 
Facility to traverse a link from more than one resource
3. Extended link group
 
Facility to construct a link in some documents from another document
 
If we try to implement this annotation facility in the current WWW environment, this function will be completely application independent because of the lack of these facilities in the HTML link. The lack of a multi-directional link fac ility means that it cannot traverse between objects, and the lack of an out-of-line link facility means this kind of link itself can never be represented at the point of link representation.
 
[3] As a result of describing annotation information as XLL, annotation information is involved in a document as a part of the link information. For this reason, even an application that does not support the annotation facility can rep resent that annotation information as a link if that application supports the XLL facility. In other words, the XLL facility gives that annotation information as much efficiency as the document itself.
 
 

4. Conclusion
 
This paper described about an implementation design of the XLL engine, which is based on HyTime, to give several kinds of link to a document management system, and defined the XLL property set. Furt her, this paper described one application design using the XLL engine.
 
This new XLL engine is easy to extend to the HyTime engine as it is designed using the HyTime property set. Moreover, the fact that this engine is designed in complicance with SGML extended facilities, which are written in Annex of the HyTime 2nd edition, means that this XLL engine also works in SGML documents.
 
Although this implementation is based on grove, we can use this design policy to construct the XLL engine based on DOM (Document Object Model), which is now under construction in the W3C.
 
Providing XML-Link facilities as the engine allows the system to be used on several applications without losing any consistency. In other words, we can manipulate SGML documents while keeping the original document's propriety because o nly the document constructed virtually in the application is operated upon and the original documents are never edited.
 
However, as described in the XLL draft, the XLL engine only understands values of viewing (timing, location) information and not defines how to manipulate the document (such as where and when a traversed resource must be viewed). There fore, there is no way to uniformly define how to view the resource, which can start traversal for identifying the existence of links. Furthermore, it is also hard to define the style specification of such resources even if a style language ( DSSSL, XSL and so on) is used to define a style. It may thus be useful to define a standard way of representing resources for allowing a user unrestricted style specification of a link.
 
The XLL engine itself is still at the research level and will be improved. We will also follow the updating XLL specification, and will append the effective facilities so that this engine can be used in various applications.
 
Bibliography
XML
"Extensible Markup Language (XML) 1.0", W3C Recommendation, REC-xml-19980210, http://www.w3.org/TR/REC-xml
XLL
"EXtensible Markup Language (XML):part 2. Linking" W3C Wroking Draft, WD-xml-link970731, http://www.w3.org/TR/WD-xml-link
SGML
Information Processing - Text and office systems - Standard Generalized Markup Language (SGML) ISO 8879:1986
HyTime
Information technology - Hypermedia/Time-based Structuring Language (HyTime) ISO/IEC 10744:1997
DSSSL
Document Style Semantics and Specification Language (DSSSL). ISO/IEC 10179:1996
SGML Extended Facilities and HyTime Two   Table of contents   Indexes   Style Concepts