Lists Home |
Date Index |
- From: "Steven R. Newcomb" <email@example.com>
- To: firstname.lastname@example.org
- Date: Mon, 31 Jan 2000 21:55:12 -0600
> 1. True or False: hyTime started (little H deliberate as a music
> standard. The problem(s) to be solved were synchronization and an
> application language for a musical notation. What requirements of music
> made the hyTime designers move into a larger scope of standardization
> (Intergrated Open Hypermedia: Bibliographic Model).
Yes, it started as an abstract music description language. The
requirements of music representation are the same as the requirements
of text representation and information management, with the added
complexity of projecting abstract time schedules from one finite
coordinate space to another.
> 2. True of False: There originally WAS a hyTime DTD. Why was
> it abandoned?
Huh? There still is a HyTime DTD. That's one of the formal
specifications of the standard; others include the SGML Property Set
and the HyTime Property Set.
> 3. When at its most widely studied, HyTime included an exhaustive
> set of linking and location models. At this point, the
> synchronization facility was expressed using these. Why did linking
> and location become the dominant feature of HyTime?
Because it was the hardest problem, and at the same time, the key
problem for the whole idea of HyTime. The solution to the addressing
problem required the highest levels of abstraction, and the most key
ideas. My perspective is that HyTime's main accomplishment, in the
end, was to make it possible to impose any combination of arbitrary
structures, rigorously and formally, on any set of components of any
kinds of information, at any level of granularity. In effect, to make
all aspects of all information, everywhere, a single (ginormous)
queriable database, or to "address any information, anywhere, any
time, in any convenient terms". Together, linking and location
addressing make it possible to create "view documents" -- lenses
through which any set of information objects appears to have some
arbitrary set of relationships among its members. (A topic map is an
exceptionally cool example of a type of "view document". It imposes
the topic map author's opinion as to the structure of knowledge, as
represented in the structure of the topic map, upon all the materials
whose contents are referenced by the topic map.) HyTime scheduling is
just another kind of imposed structure. With it, the "view document"
specifies the arrangement of the information set in finite coordinate
spaces, such as 4-D spacetime. So, addressing truly is the key to
everything in HyTime. (Most of the rest of the problem of designing
HyTime was making sure that all the kinds of imposable structure
(trees, directed graphs, and schedules) don't trip over each other and
work nicely together, both semantically and syntactically.)
> 4. True or False: Groves are a concept borrowed from DSSSL, a
> style language, itself, originally that was altered to include
> Semantics. What requirement in a linking and location standard
> resulted in a unification with the DSSSL groves concept?
At least from my perspective, it appeared to me that the grove concept
was invented and developed primarily by James Clark, with significant
input from others, as a solution to a set of addressing problems and
requirements emanating from both the DSSSL and HyTime standards,
pretty much equally. As far as I was concerned, anyway, the primary
motivation for this work was the economic insanity of the alternative:
asking SGML system vendors to implement two ISO standard addressing
languages/paradigms for SGML, (a) the DSSSL Query Language for
transformations and (b) the HyTime "HyQ" Query Language for
hyperlinking and all other kinds of component re-use. There needed to
be a single query language, and its foundation -- that is, what was
being queried, for all purposes of hyperlinking, component re-use,
formatting and transformation -- had to be strong enough to support
all of the requirements of both hyperlinking and transformation.
Thus, less would be more. And, hallelujah, the grove paradigm turned
out to be exactly that: way, way more power, using way, way less
machinery. Of course, then we had to revisit practically everything
in HyTime, because the power of the new paradigm cast a critical new
light on the design of everything else, revealing previously hidden
blemishes and inconsistencies. It was quite awkward, painful, and
expensive to fix it, even though very few people were actually using
HyTime at that time. Thinking about it reminds me, gloomily, that the
grove idea still hasn't been appreciated by the XML design community
as a whole. When the time comes to rationalize all the W3C's XML
auxiliary specs with each other, the cleanup cost is likely to be
quite frightening. A tremendous amount of good-faith effort, on the
part of many people who have been trusting the W3C to provide rational
design leadership, will be lost, and at least some of XML's current
forward momentum will have been dissipated.
> BTW: Tao. It means, "the way". In that system, there are
> many ways; they lead to the same place. Aware intelligence
> can decide to go there together.. or not. It is more important to
> understand that than it is to understand HyTime because
> the effect of community is much stronger than the effect
> of monopoly or consortium.
> Authority is choice, and
> whether as in the Tao, this is opposites, or as in Tao,
> extremes of the same continuum, intelligence still
> must choose for community.
I'll take that as a poem. (My mysticism parser must be on the fritz.)
Steven R. Newcomb, President, TechnoTeacher, Inc.
email@example.com http://www.techno.com ftp.techno.com
voice: +1 972 517 7954
fax +1 972 517 4571
7101 Chase Oaks Boulevard
Plano, Texas 75025 USA
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions and unsubscriptions
are now ***CLOSED*** in preparation for list transfer to OASIS.