Subject: Re: The DSSSList Digest V3 #48 From: "W. Eliot Kimber" <eliot@xxxxxxxxxx> Date: Thu, 27 May 1999 08:49:26 -0500 |
Let me make something very clear: There is *absolutely no conflict* between HyTime and XLink or between HyTime and XPointers (or TEI locators). This is so for several reasons: 1. XLink (as defined in the March '98 draft) can be defined as an application of HyTime. This means that any XLink document can be processed by a HyTime engine that does not have special-purpose XLink awareness. (Of course, those semantics of XLink that go beyond what HyTime was able to standardize, such as behavior, will not be provided.) [This could change if the final draft of the XLink spec makes radical changes to the March '98 approach, which seems unlikely.] 2. The abstract model of hyperlinks is fundamentally the same for HyTime and XLink. Thus we can formally define a semantic isomorphism between the two specifications irrespective of their syntaxes (should the XLink syntax eventually be defined such that statement 1 is no longer true, which would be possible, if difficult to do). 3. HyTime allows *any* addressing syntax to be used within a HyTime context (what HyTime calls "query location addresses"). All that is required is that the syntax be definable in terms of operations on groves. There cannot exist a syntax for which this is not possible (because any kind of data can be given a grove representation). Therefore, not only is the use of XPointers (or TEI locations) possible within a HyTime context, *it is highly recommended*. It is recommended because these are both very convenient syntaxes for doing addressing in certain use contexts. While HyTime provides *a* syntax for doing addressing, it does not presume that it is the best syntax for all situations. HyTime's syntax is optimized for completeness, flexibility, and indirectness. It is not optimized for compactness nor can it be used in URLs. Therefore, addressing syntaxes that *are* optimized for compactness and/or use in URLs are necessary and useful. So I don't want to hear anything more about "conflicts" or "competition" between HyTime and other facilities that do linking and addressing in an SGML/XML context, because there aren't any. The choice to use XLink/XPointer or HyTime is one you should make based on best fit for requirements. XLink/XPointer does an excellent job of satisfying the requirements of the 80% of users who need less than 20% of what HyTime offers. HyTime does an excellent job of satisfying the remaining requirements of the 20% of users who need more than XLink/XPointer provide. It's the difference between buying a VW Golf or a Volvo truck: you don't buy the former to haul goods long distances and you don't buy the latter to take the kids to soccer. XLink provides a natural and smooth migration path to a more-functional HyTime-based solution, such that as you reach the limits of what XLink provides, you can start adding the HyTime facilities you need without the need to change your existing data (you will, of course, need to change your DTDs, but not the instances they govern). By the same token, if you implement an XLink engine, you will have already solved most of the hard problems inherent in building a HyTime engine, such that moving from XLink-only support to more complete HyTime support is an incremental effort, not a total re-implementation effort. And, it is not true that "HyTime has not been widely implemented". Synex's Viewport engine implements a significant part of HyTime. Viewport has been widely used and deployed. What *is* true is that the full feature set of HyTime (or even of the location and linking modules) has not been widely implemented. But it has been implemented in a variety of ways and will be more widely implemented very soon. For example, TechnoTeacher will soon release version 1.0 of their GroveMinder tool which will include a full-featured HyTime engine (for a demo, send email to Steve Newcomb, srn@xxxxxxxxxx). My PHyLIS tool (www.phylis.com) is a reasonably full-featured HyTime engine implemented in Visual Basic [PHyLIS is an educational toy, not a production-quality product]. I have personally implemented HyTime functionality for production use in ADEPT*Command Language, Perl, and DSSSL. The Topic Map standard, ISO 13250, is a HyTime application that will soon be supported by a number of commercial products. Cheers, E. Ralph Ferris wrote: > Date: Sat, 22 May 1999 06:00:27 -0400 > From: Norman Walsh <ndw@xxxxxxxxxx> > > >Personally, I wouldn't characterize XLink and XPointer as > >"competition" with HyTime, just an alternative. But I agree that > >HyTime is less likely to be implemented. But HyTime has never > >been widely implemented. > > >Date: Sat, 22 May 1999 10:31:54 -0400 > >From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> > > > ><reply> > >...So, it remains that XLink/XPointer > >and Hytime are competing for "market share" (i.e. the biggest number of > >implementations) and mind share (i.e. the biggest number of people knowing > >these specifications). Actually, Hytime starts with a handicap. A not > >completed spec is more popular than a mature spec (since several years). > ></reply> > > Actually, the XLink/XPointer vs HyTime issue is part of a longer standing > issue: HyTime vs TEI. Years before there was an XML, Steve DeRose and Dave > Durand wrote "Making Hypermedia Work, A User's Guide to HyTime." This > "HyTime" book included a section on TEI pointers that made it pretty > obvious which approach the authors' preferred. DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: The DSSSList Digest V3 #48, Ralph Ferris | Thread | RE: The DSSSList Digest V3 #48, Didier PH Martin |
RE: TeX backend (was re: The DSSSLi, Norman Gray | Date | RE: Indexing, Harbarth, Juliane |
Month |