HyTime, XLink and XPointers (was Re: The DSSSList Digest V3 #48)

[Ralph Ferris <ralph@xxxxxxxxxxxxxxx>]

At 09:48 AM 5/27/99 -0400, W. Eliot Kimber wrote:
>Let me make something very clear: There is *absolutely no conflict*
>between HyTime and XLink or between HyTime and XPointers (or TEI
>locators).

In the technical sense, no. HyBrick, after all, implements XPointer in
terms of the HyTime property set.

>
>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 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,

The operant phrase here is "migration path." For those who believe that
SGML, and by extension HyTime, are still "viable" standards, the "migration
path" concept makes sense. But that point of view has never been endorsed,
either formally or informally, in the work on XML. 

On the contrary, consider, for example, the comment by James Clark, who
wrote to the DSSSList a few days ago:

> My general feeling is that just as the future is XML not SGML, so the
future is 
> also XSL not DSSSL.

Those who agree with James' statement are unlikely to support HyTime
"migration"; they are more likely to add "the future is XLink/XPointer, not
HyTime." And that makes the work on XLink/XPointer open-ended, *if these
specs are to support the vertical apps I alluded to in my last message.*  

Given the choices:

- migrate to SGML/HyTime for vertical market apps, or
- re-write the DTDs and/or expand the XLink/XPointer specs to support these
apps

many people seem to think the latter is what will/should happen. In fact,
wasn't that the first response by many vertical industry work groups -
announce they were XML-ifying their DTDs - because free XML browsers from M
& N are going to support all these features, regardless of how complex they
become?

Best regards,

Ralph E. Ferris
Fujitsu Software Corporation


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist