ms6b+@ANDREW.CMU.EDU (Marvin Sirbu) (08/24/90)
Jonathon's original list of possible starting points for document standards included CDA from DEC. In fact, DEC provides for exactly the notion that Craig describes of sending along application code, or the name of the appropriate application to use, in order to view/edit/manipulate a particular type. Because CDA was designed by DEC to support the DEC product family, (only two hardware architectures) DEC can assume that the requisite applications are available throughout the universe DEC intended CDA to operate in. The idea of using some widely available program and its data file as a component of multimedia mail has several defects: 1) you are limited to the capabilities of the particular software package in terms of that type. If Lotus 1.0 is your standard for spreadsheets, they you can't send three dimensional spreadsheets. Jon made a similar point using the example of margins. 2) you are limited to the platforms which support the standard application. or at least support the standard application's file format. (I can send a Lotus file to a Mac and read it with Excel because the Lotus file format is widely read.) It also has some advantages. Now, the fact is that IBM PCs are so widespread that a lot of useful multimedia interchange could conceivably take place just by sending around combinations of Word Perfect + Lotus files. And those who are anxious to get some real multimedia going now, but don't care about universality and generality can get started that way. By contrast, if you believe that 1) we need standards that support interchange with machines that Lotus doesn't run on (yet...); or 2) if we look at the functionality of lots of spreadsheet programs (substitute text, graphics, music, etc.) we can define a file format which supports the union of all the capabilities in all of them, then, you try and develop or extend something like ODA. Standards like the ISO standard for exchanging computer tape at 800 bits per inch started out as the IBM tape drive product. Because IBM tape drives were out there, there were a lot of them, and they worked, other vendors made products that would work with the IBM written tapes. Eventually, the characteristics of the IBM product were written down as a standard. The de facto capabilities of the IBM product, and its limitations, became the stanadard because that was the easiest thing to do. The test for compatibility was, "Can a tape written on drive X be read by an IBM drive?" By contrast, other standards, like the Intelligent Peripheral Interface (IPI) represent technological combinations which were put together for the first time in a committee, and attempted to include ideas from many different sources. There was no reference implementation, and each vendor worked on implementations which would conform to the document, not to some reference implementation. Not every implementation of IPI provides all the features of the documented standard. So both approaches to standards development have historical precedent. However, it is worth pointing out that there has been a relative decline in the success rate of de facto standards, and a marked increase in standards designed by committees over the last 15 years. While I am not sure I can explain why fully, I believe it is because of the increasing heterogeneity of information technology hardware and users. There are no firms with the dominating power of an IBM or AT&T of the 1960s, nor, arguably, is even the IBM PC such a dominant de facto architecture. Thus, it is not realistic to expect a standard developed around "popular" applications to become a sufficient de facto standard to really be universal. On the other hand, standards processes are so slow, that you can do an awful lot of useful work based on the other approach while standards are being developed -- as, evidently, DEC has decided in bringing out CDA. Marvin Sirbu CMU
craig@gpu.utcs.utoronto.ca (Craig Hubley) (08/24/90)
ANDREW.CMU.EDU!ms6b+ (Marvin Sirbu) says: >Jonathon's original list of possible starting points for document standards >included CDA from DEC. In fact, DEC provides for exactly the notion that >Craig describes of sending along application code, or the name of the >appropriate application to use, in order to view/edit/manipulate a I don't know much about CDA, but from this information it would seem that CDA plans to take a pretty general object-management approach. However, I am not sure if its philosophy is that there should be only *one* object- management scheme, and that all resources should be accessed that way. Now that DEC is releasing its Trellis object-oriented system, perhaps some framework will be provided there for building CDA-compatible types... perhaps the DEC object database itself will provide this capability using Trellis... this would be interesting, because the line between "media" and "application" would be blurred out of existence. As I think it should be. >DEC product family, (only two hardware architectures) DEC can assume >that the requisite applications are available throughout the universe >DEC intended CDA to operate in. This is similar to the use of tar, troff, csh files and the like on Unix. >The idea of using some widely available program and its data file as a >component of multimedia mail has several defects: >1) you are limited to the capabilities of the particular software package >in terms of that type. If Lotus 1.0 is your standard for spreadsheets, >they you can't send three dimensional spreadsheets. Jon made a similar >point using the example of margins. Yes, the best you can do is to send three dimensional spreadsheets in Wingz format, and provide a fallback Lotus version, or rely on an intermediary (which knows what the receiver can do) to translate one to the other. Lotus isn't really your 'standard' (in fact any available translation from one format to another could be invoked) but if you go beyond its capabilities you risk translation not being available. Such a system makes it possible to move incrementally towards an interchange standard, however. At first it is provided as the fallback, but as more and more applications support it, it becomes the first rather than the last resort. In effect, it moves from supporting a N**2 1-1 translations to supporting N many-1 translations. But N is not very large in the beginning, and as it grows, so does support for the interchange standard. There is also the potential for chained translations, say Wingz->Excel->Works or something, but of course the longer these get the more information you are likely to lose. A generalized conversion scheme like that in C++ would be useful. Use C++, and you'd get it for free... :) >2) you are limited to the platforms which support the standard application. >or at least support the standard application's file format. (I can send >a Lotus file to a Mac and read it with Excel because the Lotus file format >is widely read.) Yes, this is potentially very debilitating. I am relying on the application software vendors to make their systems available on my platform, or on other vendors to build systems compatible with their formats. This is a slow process - *almost* as slow as standard-setting. However, there are some companies out there, like WordPerfect or Oracle, that are hell-bent to get themselves on practically any platform that can run the product... that becomes a more supportable strategy under an object management system, since you may become the de facto representation standard for your doc-type. >It also has some advantages. Now, the fact is that IBM PCs are so >widespread that a lot of useful multimedia interchange could >conceivably take place just by sending around combinations of Word >Perfect + Lotus files. And those who are anxious to get some real >multimedia going now, but don't care about universality and generality >can get started that way. I wouldn't say I don't care, but I sure think there are some issues to work out that don't require universality or generality of types or of platforms... Universality and generality are always relative, anyway. I haven't heard anyone talking about virtual reality interchange standards, or multimedia document systems that will run on an Apple II. >By contrast, if you believe that >1) we need standards that support interchange with machines that Lotus doesn't >run on (yet...); or Can we build such standards, and perform such interchanges, while still letting PC users swap around their spreadsheets ? Will ODA let us encapsulate Lotus, with all its pluses and minuses, as an ODA-format type, that can be included in ODA documents, and provide a means of getting the list of types in the document so that mailers, forwarders, and receivers can perform translations, fallbacks, or rejections ? >2) if we look at the functionality of lots of spreadsheet programs (substitute >text, graphics, music, etc.) we can define a file format which supports >the union of all the capabilities in all of them, >then, you try and develop or extend something like ODA. I agree this should be done, but no standards committee can do it correctly, once and for all. A more incremental process of type design, construction, and testing needs to be supported, and if you always wait for a world-standard need for a new type to develop before building it, your system runs the risk of irrelevance. >Standards like the ISO standard for exchanging computer tape at 800 >bits per inch started out as the IBM tape drive product. Because IBM >... >Interface (IPI) represent technological combinations which were put >together for the first time in a committee, and attempted to include >... >So both approaches to standards development have historical precedent. Good examples! But can we find a precedent for an extensible standard ? That is, where the means of extending its capabilities were well-defined ? Ethernet packet types might be an example. The beauty of Ethernets is that dozens of machines can all inhabit the same Ethernet, all speaking totally different protocols to each other. As the world standards bodies hammer away on a single OSI protocol that they can speak to each other, they can still speak TCP-IP, DECnet, XNS, or whatever else you like... and gateways can translate one into the other. These systems are useful today, and the same framework will be able to support the OSI protocols incrementally as they are developed. But the migration will be slow. Even if you had a standard spreadsheet type tomorrow, Lotus would take a long time supporting it. In fact, they might not bother until they were supplanted as the de facto interchange format... >However, it is worth pointing out that there has been a relative decline >in the success rate of de facto standards, and a marked increase in standards >designed by committees over the last 15 years. While I am not sure I can How about their success rate ? >explain why fully, I believe it is because of the increasing heterogeneity >of information technology hardware and users. There are no firms >with the dominating power of an IBM or AT&T of the 1960s, nor, arguably, >is even the IBM PC such a dominant de facto architecture. Thus, it >is not realistic to expect a standard developed around "popular" applications >to become a sufficient de facto standard to really be universal. One could argue that industry groups like X/Open, OSF, and Unix International, plus some dominating players like Microsoft, have taken over this kind of role. Of course, often these are just the old players in new disguises. But paralleling the growth of diversity in hardware and users is increasing recognition among the players that they do better by voluntarily cooperating. This has been proven in niche markets (Amiga developers supported IFF and AREXX because they would have found it hard to sell their product at all without them) but as competition in major markets increases, so does the pressure to cooperate, if only to define spheres of influence. >On the other hand, standards processes are so slow, that you can do an >awful lot of useful work based on the other approach while standards >are being developed -- as, evidently, DEC has decided in bringing out CDA. DEC is also thinking more generally about the object management problem - that is, they are building an object database and have joined the OMG... they may be thinking of CDA as a prototype for an even more general system that would go beyond 'documents' into arbitrary software objects, including those with types defined fully by a user and shared by a group - a basic capability of object databases. This would be something to watch for... then you would be able to support the user-defined, corporate-standard and world-standard types alongside each other in the same system... so more functionality is available within a tighter circle, but less is shared in common as you move outward, and in the outermost circle the only guaranteed means of exchange is the relatively small set of world standard types. As these increase in number, the lowest common denominator system expands, and slowly the user-defined types are replaced... but only incrementally. And without ever losing their functionality. Can I have my cake and eat it, too ? Craig Hubley kid after Live Aid: "Is that it?" Craig Hubley & Associates --------------------------------- craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig -- Craig Hubley kid after Live Aid: "Is that it?" Craig Hubley & Associates --------------------------------- craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig
vcerf@NRI.RESTON.VA.US (08/24/90)
Marvin, thank you for a nicely-reasoned note about object standards. I wanted to respond to one element of your commentary: speculation about why the standards process has shifted from selecting among options from de facto "tried and true" methods to "ab initio" standards, usually developed by committees committed to standards-making. In the last 15 years, product and service providers have come to recognize the commercial value of standards. However, standardization stimulates competition. As a result, the vendor world has incentives for the following kinds of behavior: 1. avoid adopting a competitor's "standard" because it puts you on the disadvantaged side of the ledger (the competitor has already implemented it). 2. avoid agreeing to a standard until you are ready to productize based on it 3. try to assure that the standard puts all competitors at equal disadvantage. I am sure you can think of more examples. I don't mean either to be cynical nor to chastise the vendor community, since I believe these behaviors are rational in the marketplace if disappointing from a more lofty, academic perspective. But I think it helps to appreciate the shift in the way in which standards are viewed. Since there are a lot of other people participating in this discussion, I would be quite interested to hear if others disagree with the view expressed above. Since this topic is not exactly aligned with the substance of MMM-PEOPLE, perhaps these comments could be sent to me directly to avoid boring folks who would prefer to concentrate on the technical debate. Vint
Stef@NRTC.NORTHROP.COM (Einar Stefferud) (08/24/90)
Picking up on Vint's comments, I just want to emphasize that the reason
why I would like to see some IFIP WG 6.5 work done that focuses on
issues that are currently beyond the work of the standards bodies is to
avoid the worst of the implications of Vint's observations.
After work starts in the standards bodies, all of what Vint observes
will kick in and it will become very difficult to discover ways to
achieve a good design.
So, lets step ahead and work beyond where the standards bodies are
working so as to get a jump on them for the next round. The work I am
visualizing has to do with conceptual modeling and articulation, along
with surveys of all the ways things are now being done, and what the
standards bodies are working on, plus research on new ways to do things.
Those folk who do not like to do such work are not invited. I would
hope that they will not begrudge us the possibility of doing the work
that we want to do.
We certainly do not suggest that anyone else stop what they are doing
and wait for us to deliver THE ANSWER! There may not be any ANSWER.
But this possibility should not stop anyone from searching and
researching.
As I read much of the recent MMM traffic, I cannot help but feel that we
are mixing our time frames, and I feel caught in a time-warp. On the
one hand some are trying to discuss new broad concepts, while athers are
saying "that can't be done right now" or "but how about all the PC folk
who want to do somethign right now with what they have?"
We should not try to hold both discussions in the same "room". So, lets
try to find some way to segment this discussion into:
1. What to do now with what we have now; and
2. Ignoring todays problems with what we have now, what can we
consider doing in the future?
Best...\Stefjxr@THUMPER.BELLCORE.COM (Jonathan Rosenberg) (08/25/90)
Einar, I think your latest post has hit the nail right on the head: > As I read much of the recent MMM traffic, I cannot help but feel that we > are mixing our time frames, and I feel caught in a time-warp. On the > one hand some are trying to discuss new broad concepts, while athers are > saying "that can't be done right now" or "but how about all the PC folk > who want to do somethign right now with what they have?" > We should not try to hold both discussions in the same "room". So, lets > try to find some way to segment this discussion into: > 1. What to do now with what we have now; and > 2. Ignoring todays problems with what we have now, what can we > consider doing in the future? Just to be clear, I would place myself firmly as being interested in 2., but I would reword it as: 2. Learning from todays problems with what we have now, what can we consider doing in the future? Thanks for your insight, Einar. JR