xml-dev - Re: ATTN: Please comment on XHTML (before it's too late)

["W. Eliot Kimber" <eliot@isogen.com>]

David Megginson wrote:
> 
> W. Eliot Kimber writes:
> 
>  > > You and I, Paul have seen too many worthy specs fail completely
>  > > because of superfluous complexity -- HyTime, Topic Maps, and DSSSL
>  > > (and Architectural Forms) spring immediately to mind, but they hardly
>  > > stand alone.
>  >
>  > This is pure flame bait and has no place in this discussion.
> 
> Apologies -- I listed these because (with the exception of Topic Maps,
> which I don't know as well) they're all specs that I was personally
> very fond of and spent a lot of time working with.

Appology gladly accepted--I didn't think you were really trying to bait
flame. But I think your tone of despair, while understandable, is
unwarranted, at least so far.

> Unfortunately, simply satisfying requirements is not a reasonable
> success measurement for specifications.  The only justifiable reason
> for putting time and effort into standardization (especially for an
> International Standard) is to achieve the network effect, so that a
> lot of people sharing the same spec can share information and/or
> implementation work: boxcars can run on more than one railroad's
> tracks, IP packets can travel across more different kinds of networks,
> I can plug more than one brand of phone into my wall, I can use the
> standard C++ library on both Unix and Windows, etc.
> 
> Perhaps it's too early to judge, and HyTime and DSSSL might still
> reach this point, but they have not done so yet despite the enormous
> efforts that people like James Clark, Paul Prescod, Eliot Kimber, and
> me have put into implementing and explaining them.

Agreed that the network effect is the goal, but it holds at different
scales and need not hold at the highest level to have achieved
significant benefit.

I think that it is *way too early* to judge. HyTime and DSSSL are only
two years old. We are just now getting HyTime implemented in an
industrial strength way. From this experience, we will need to make a
number of adjustments to the spec to fix real bugs, fill holes, etc. 
That means we're really not even fully out of the shute yet.  There are
a relatively small number of early adopters who need what HyTime can
provide. There are a large number of others who need it but either don't
realize it yet or require a much more pervasive technology base. The
HyTime design is good--if you try to solve the same set of problems
you're going to come up with pretty much the same answer we did, I'm
pretty sure, so I'm betting that when the masses finally understand the
nature of the problem and the type of solution they need, that HyTime
will be very attractive. In the mean time, I'll keep doing what I can
with it.

At Metastructures, I presented on work we're doing to implement a
reasonably-large-scale HyTime-based system at Woodward governor. This
will be our first production use of HyTime and GroveMinder
(TechnoTeacher's HyTime middleware product) that we can talk about
openly. I think it will serve as a dramatic demonstration of what the
technology does and help move things along. 

Note too that I consider XLink to be part of the HyTime effort because
it makes the core concepts of HyTime easier to see and use. XLink's
semantic and syntactic models are fully compatible with HyTime's so
XLink provides a smooth migration path from the simple applications to
more sophisticated ones. And again, there's a difference in requirement
sets: XLink is optimized for ease of delivery and processing, HyTime is
optimized for flexibility and ease of authoring (many of HyTime's
features are there to minimize the syntax authors have to type when
creating links).

I would also consider HyTime a success if it contributed to the
development of a new standard that solved the same problems but, for
whatever reason, was more accepted. 

Cheers,

E.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)