Welcome to the Fourth International HyTime Conference.

I'm Steve Newcomb, serving again as your Chairman.

I suggest you all get to know everyone you meet here. I think this may be the last really small and intimate HyTime conference, because I think the use of HyTime has just begun to explode. Future HyTime conferences will be attended by veterans and newcomers, but you will always be among the elite veterans who saw the explosion coming and were prepared for it. Each of us will probably turn out to be an important resource for others of us. It's important to make new personal connections during these two days. I personally would like to get to know each of you. If time doesn't permit that to happen during these two days, I would like to do that afterwards. (I'm planning to stay for the XML Developers' Day session on Thursday, too.)

I'd like to give you some advice. At the luncheons and breaks, make a point of conversing with people you don't already know; try to pick a table where you don't know anybody. If possible, volunteer the reasons why you're here, and what you're looking for from HyTime and from the conference. Talk about substance: things that affect you and your business, and the substance of the presentations. You have nothing to lose, and everything to gain. I have learned a lot by using this technique at conferences. Of course, I have a personal reason for asking you to do this: in the explosion of adoptions that will occur during the next 12 months, all of HyTime's personal networks will be used. There is certainly going to be a shortage of people who know anybody who has used HyTime. As Benjamin Franklin once said to the framers of the U.S. Declaration of Independence, "We must all hang together." (In its way, HyTime is just as radical and far-reaching as any declaration of independence.)

And now comes the time for my usual brief inspirational harangue, which I get to do just because I'm the Chairman of this conference.

As usual, this year's sermon has to do with the advancement of humanity and its ongoing invention of civilization. This year, though, I'd like to share with you some thoughts about productivity. The more productive we are as a society, the higher the living standard for each individual can be. HyTime offers substantial productivity improvements for information managers (and everybody is an information manager).

I've made kind of shopping list here of ways in which the HyTime second edition improves productivity. I don't think the list is complete, but it's what I've come up with so far. (If you can think of any other ways, please let me know.) Many productivity improvements can be realized by using the notion of inherited architectures:

• Information architectures and syntaxes are recyclable. The effort of creating a DTD or architecture need not be repeated.
• DTDs can be placed under the control of writers without losing interchangeability. Productivity that has been lost on account of inadequately specific or specialized DTDs, or on account of the destruction of keyboards and monitors by frustrated authors, can be regained.
• The evolution and specialization of information architectures is easier and cheaper; simply mine the architectures (DTDs) that are derived from base architectures for ideas for improving the derived architectures. In many organizations, the existing layers of nonproductive and counterproductive bureaucracy involved in creating and approving ad hoc changes to information architectures can be abolished.
• The independent evolution of many small, modular architectures is a safer process than the managed evolution of a few monolithic DTDs. Unintended side effects of changes are easier to avoid, and they are less damaging because of their limited scope. A free market of architectural ideas is more productive than a "command economy" dominated by fewer and fewer information architectures that, like cancer, grow larger and larger and consume more and more resources to maintain.
• The act of inheriting and combining multiple architectures, "multiple inheritance," is in fact an act of recycling existing work in new ways. The cost of combining separate architectures into a single inheriting architecture is very low, because structural and semantic conflicts and redundancies are easily resolved.
• Everybody gets smarter about architectures: It's OK and easy to use whatever is useful. Rational architectural designs become popular by virtue of their ability to enhance productivity.
• There is less incidental loss from commercial warfare over proprietary architectures and pet architectures. Everything is OK; every kind of architectural notion can coexist peacefully, even in the same document.
• Everybody gets smarter about everything: Interchangeable knowledge representations get richer, more powerful, more diverse. Even so, there is less isolation of user communities, and cross-domain knowledge sharing gets easier.
• There is less metadata loss: metadata architectures, like any other architectures, can be mixed, matched, and mapped.
• Software for the support of small, modular architectures can sold for less per seat. This is because each modular architecture engine is useful in more contexts, has more customers, and it can therefore be sold profitably at a lower price.
• Competing software engines for the support of small, modular architectures are more generic and similar. Therefore, buyer choices can be more rational, based on relative features, performance, and price. Being able to buy products from the lowest bidder is a significant productivity improvement.
• Assuming that architectures can become more stable, due to their greater modularity and reduced scope, software engines for architectures can have a sufficiently long lifecycle that for the majority of their useful life, they can become more powerful and reliable. Higher power and reliability translate directly to increased productivity.
• Software applications can be built faster and more cheaply. All the needed architecture processing software can be bought off the shelf and integrated. This allows application developers to devote all their time and attention to the GUI and the other application-specific processing software.

Productivity enhancements can also be realized by using the grove and property set paradigm described in the 2nd edition of the HyTime standard:

• Property sets are like abstract APIs to documents in any given notation (such as SGML) or architecture (DTD or schema). They are reusable, so they only have to be created once for each notation or architecture. Once created, each property set guides the development of software engines, as well as the syntax of an SDQL query.
• Because of property sets, again there is a decrease in the loss of metadata. Addresses used to associated metadata can be expressed in terms of standard, technology-independent names for the semantic properties of notations and architectures.
• Confusion is at the root of much lost productivity. A property set for a notation or architecture can be used to provide a rigorous, interchangeable expression of its properties. Given a property set, there can be little confusion about the requirements governing the design of application-specific data processing software.
• Finally, the use of property sets can reduce implementation errors. Property sets are in fact SGML documents, and they can be parsed into their component parts and then reformatted in such a way as to describe an API for an engine that understands the property set. By using a special combination of tools, programmers can create applications and processing engines for a property set at least partly automatically and without error.

So that's my list of productivity enhancements provided by HyTime.

Now I'd like to make some sound-bite remarks.

1. It's pretty obvious now that XML is probably going to be significant. XML should not only be the easy on-ramp to SGML; it should also be the easy on-ramp to HyTime. Regardless of how much or how little XML's design or syntax resembles HyTime, HyTime is here to stay in any case.
2. The US healthcare industry is going to be a major early adopter of the notion of inheritable architectures. We have two talks about this topic tomorrow afternoon.