HyTime International Conference
Seattle, WA,
20-21 August 1996

<- Michel Biezunski -> High Text Michel Biezunski, High Text, S.A.R.L.

<- Michel Biezunski -> Invisible HyTime


Summary

A paradoxical situation and its remedies

This talk is motivated by a paradox in which we are today: HyTime is not yet a hot issue, it's very difficult to get people attracted just by saying HyTime and at the same time it's the moment where real applications are starting.

Hide the scaffolding, Reveal the hidden beauty

There are three aspects in HyTime: conceptual, political and technical. Scaffolding is the set of technicalities: a set of supplementary SGML features. The hidden beauty is the set of powerful concepts on which it relies. HyTime is looking ugly because it's new. As major scientific discoveries, the way it's expressed by the inventors has to be worked out and transformed before it becomes workable.

HyTime's new look

<- AFDR -> <- Architectural Form Definition Requirements -> <- Hyperlink -> Technical corrigendum : Separation between "SGML Extended Facilities" including AFDR and the HyTime's specific five modules for addressing, hyperlinking, measuring, scheduling, rendering.

Even if it requires a lot of work and attention from the experts in charge of it, it is not a major upgrade, but just technical reorganization, from a user point of view.

The HyTime Decision

Information architecture - Choice The decision to choose HyTime as a base for representing information architectures can only be taken by people who understand the political and conceptual issues involved. Choosing HyTime is not only a question of getting the appropriate technology. Worst, it can be misleading to just rely on the available technology.

The situation is not different from SGML at the beginning. SGML has never been a better technological solutions (cheaper, quicker, simpler, easier) than other available solutions. It doesn't mean SGML should be rejected though.

HyTime Tool Is there such a thing called a HyTime tool?

Tools are interesting if they fit user needs.

What comes first? Tools or User needs? There is no simple answer. It depends of the kinds of users:

Today, HyTime is only interesting for the second kind of users.

The consequence is that only those who can invest in promising future technologies to emerge can be interested.

But ... not a lot of users are satisfied with today's existing technologies in general. This is why the activity in the software industry remains so frantic.

SGML Technology The SGML technology

HyTime applications are built with SGML-based technology.

HyTime is a part of SGML, and the SGML technology can be used for HyTime applications. Most existing HyTime tools today are SGML tools which is being specialized or extended to interpret the semantics provided by HyTime architectural forms.

<- HyTime Engine -> But this is true at the syntactical level, not at the end-user level. HyTime Engine and even Architectural Forms Engine do exist, but the question remains: what use can be expected from HyTime at all?

HyTime Application What does "a typical HyTime application?" mean

To which process(es) a typical HyTime application fits in ?

Except for interchange purposes ("press a key and your database will export HyTime"), the question is for a user what advantage he gets from having a HyTime-compliant tool?

The multimedia applications are not ready for HyTime yet.

The first generation of SGML tools have been designed to accomplish a well-known process of publishing: SGML-conforming text editors, formatters, browsers have been created by respecting a well-known publishing process.

What is the equivalent for the HyTime market?

Interchanging interconnected information

Ilink Focus will be now on one architectural form: independent link

HyTime provides new, unheard-of, sometimes not-thought-of, types of user interaction that can be applied in different fields. HyTime is so wide and so ambitious in its scope that it can practically do anything. But this is also discouraging. By definition, users are not looking for potential, they are looking for usefulness. This paper will focus on single architectural form out of about 70, the independent linking feature of HyTime, which covers the work we have been doing since about 3 years in this field.

Three aspects will be discussed: the conceptual side, the political side, and the professional side, before presenting the fundamental principles on which we have designed one specific application.

Linking versus Addressing The conceptual side: Linking is different from addressing.

<- Anchor -> <- Hyperlink -> This is a major breakthrough compared to the traditional hypertext approach ("click and see"). It describes what is related and why it is related. If we are not able to know what's at the other "end", it doesn't work. For 2 reasons: there is no such thing as a "start" and an "end". A number of things are related, and it's possible to restrict traversal rules for example in only one direction, but it is meaningless to try to say where is the origin and where is the target when for example 5 different objects are related together. They just happened to be related, HyTime says. The impact of this is tremendously important: it means that in order to interconnect information, one must know by advance what is the role played by what is becoming an anchor. Anchors can be anything, they don't have to be modeled as anchors. They are just "anything that can be addressed using a HyTime address". And as a HyTime address can point to anything, it means that every single piece of information is a potential anchor.

<- Entity-Relationship Model -> 2) More than an entity-relationship model

HyTime ilinks include the entity-relationship model used in databases. makes information visible once it is interconnected. It is like a database scheme and it prepares the long-term starting merging between the document world and the database world, already starting with SGML. HyTime adds to the entity-relationship model the addressing capabilities.

Ilink - political side The political side: knowing / learning what others are doing.

<- Architectural Form -> <- DTD -> It is a direct consequence of the conceptual side. One can only connect to something else by knowing / learning what others are doing. Why? Because the anchrole attribute is mandatory. A HyTime link is no more than an SGML architectural form that provides the knowledge of the semantics of any relation. Now the question arises of which part of the information set one is in control of. At least one need to have to knowledge of what is the information which one is relating to. This is similar to the DTD requirement in SGML. Prior to create any document instance, one must think about the structure. It's a "think before doing anything" kind of requirement. However, putting semantics into the relation itself means that it's possible to add alternative views on information regardless of what it was intended for. This is the consequence of the fact that HyTime allows to address anything, and that the semantics is in the link. Therefore, one can create as many views as desired into an information set.

Ilink - Professional side The professional side: New skills required

Address Integrity <- DTD Design -> <- DTD -> <- Reference -> Address integrity is a technical issue (for writers, for computer scientists, for database administrators, for system administrators, for network/Web administrators, for publishers, for librarians, etc.). It's important that the reference is correct. Knowing how to express correctly either a bibliographic reference, or a computer identifier is a technical issue, which is fulfilled by skilled people in the different fields. Using computers should on the long term help resolve addresses in a way which is more comfortable than the way it is done by traditional referencing. It requires a completely different set of skills to not only know what other people are doing, but how they are doing it in a certain way. One needs to be in a more powerful position to do so, because some people might not appreciate that others look with so much attention into their reserved domain. But interconnection of information has a price, and this is the real issue involved. HyTime only makes it visible. This is parallel to what happened with SGML. The DTD design is something that has to be done by information owners rather than by computer scientists. The information owners have gained more control by using SGML. Using the HyTime ilink feature gives them an even greater control.

Research-development still needed

<- DTD -> Information Architecture Modeling Topic Map Architecture <- Topic Map -> <- CApH -> <- MID -> <- Topic Navigation Maps -> HyTime modeling is a challenging task, because it involves changing the way we think about the very nature of information. The experience of the Topic Map architecture is interesting to recall. It starts with a user requirement from Unix vendors who wanted to interchange indexes, glossaries, thesauri, and after two years of meetings abandoned for the main part the HyTime way to concentrate on a classical SGML DTD. But the group continued to work, and the resulting architecture is now becoming an international standard, and it's deemed to success, although it might still take some time before practical implementations will be demonstrable. The other planned directions of work of the CApH group are very ambitious too: modification history, natural language, access policy, geographic information systems, are items which have been discussed as possible future architectures based on HyTime. It's possible to add to that specific domains, such as medical information or legal information management, that have their own requirements, including scheduling information in time and space. Another direction showing the potentialities of HyTime is the work made by the MID group on a language which describes among other things the ways a document can interact with its users.

A shared effort

<- SGML Architecture -> <- CApH -> Development of HyTime-based architectures take therefore a lot of work, time and resources, and are probably not under the reach of small companies, or even companies which want to have an immediate implementation. It's best fitted for those who have a long-term perspective in mind, and can at the same time accommodate the existing technologies for doing what they need today and prepare more powerful information management approaches for tomorrow. This seems somewhat impractical unless consortiums are formed, on a professional or international level, to make this happen. The CApH group has not been able to meet for the last year and a half because of lack of resources of those involved, more or less on a benevolent basis. It's time to think on a future that can be shared together, and start to merge ressources on projects that are in the interest of the community as a whole. HyTime has everything within it to satisfy these needs. The only thing needed now is to find people enough motivated to support this process.

A new user interface: Make HyTime comfortable to use

<- User Interface -> A view on information is a user interface. The tools to make it work are part of that interface, but are not the interface itself. Because HyTime is an international standard, a lot of tools can be built using various technologies, including all levels of SGML purity and non-SGML technologies, such as databases.

The traditional hypertext user interface

<- Reference -> This interface is based on the notion of a reference. A reference is a uni-directional type of link which contains addresses and sometimes some semantics.

<- HTML -> To create a link: start from the origin, highlight the target, and a smart application will put the address of the target right in the origin, with the appropriate markup for a link. Examples are SGML id-idref referencing, and HTML hypertext references (HREF):

<A HREF="another_document"> or, if the application is more sophisticated:<<A HREF="another_document # a_location_in_that_other_document">

Why are HyTime ilinks different from other links?

An ilink is a relation between a set of anchors. Each anchor can in turn be made of a set of addresses. The two levels of groupings are different. This is a requirement imposed by the way the standard defines the ilink architectural form.

A user interface should :

What should be hidden from the user?

<- Addressing -> Addressing mechanisms

What should be shown to the user?

Semantics of linking

A user interface for ilinks should then:

Take care of the management of IDs (automatic invisible process)

Be able to locate information transparently just by supplying the context of the SGML tree (or grove).

Implement built-in traversal rules, allowing the user to navigate within an aggregate, depending of the value of the aggloc attribute. If this value is aggloc, traversal is possible from the aggregate to each of its member, whereas if the value is agglink, traverse is possible like within a pull-down menu, i.e. from the aggregate to each of its members, and from one member to the next and vice-versa.

Creation of a link

In the hypertext (or contextual) way. Be at the origin. Highlight the target.

For an ilink way, it does not realistic to think about a universal type of user interface, because the reason why there are ilinks and the way they can be implemented is widely open. Therefore, this depends on the application.

The motivation for designing wide-open types of applications is to allow technology to be built to fit general needs that have been identified.

<- Topic Map -> The Topic Navigation Map architecture is an example of those. It allows information owners to describe the equivalent of indexes, glossaries, thesauri and cross-reference by building a knowledge base called a Topic Map.

<- Ilink -> <- Topic Map -> In the Topic Navigation Map architecture, there are only two types of ilinks:

<- User Interface -> User interface for topics in a topic map

A typical user interface for a topic map would then contain the features needed to declare an object as the anchor of a given link (i.e. a given topic. The process is very similar to the one used while indexing a document.

The question whether this process should be done automatically versus manually is an implementation issue, not an interface issue.

On-line help for interactive entry

Supplementary tools are needed to help users who need to enter manually the above information.

<- User Interface -> <- Topic Relation -> User interface for topic relations

User Interface Features of the user interface

In order to facilitate the ease of use, the interface should contain features that are automatically triggered either during the process of the creation (interactive mode) or after it (batch mode).