|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: ATTN: Please comment on XHTML (before it's too late)
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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








