[DMcCunney]

Originally Posted by fjtorres

We may by dealing with semantics but in the real world there is a difference between standards and paper specifications. Standards are tied to actual products and there are penalties for not adhering to them (as MS discovered when they licensed Java and didn't read the buried fine print).

Agreed in the sense that a standard is useless if it isn't actually implemented by any products. The point to a standard is something everybody can implement and use.

Since the products which implement standards are sold for money, there is a lengthy and highly political process involved in making something a standard. Various players in whichever industry will say "We're all in favor of standards. Do it our way!". Depending upon the standard being hammered out, there may be several incompatible approaches being put forward. In some cases, companies have made bets that their approach, or something close too it, will be anointed as the standard, and have shipped prodcuts based on it, so the stakes can be high.

Specifications simply list product features and components or attributes.Epub aspires to be a standard but the bodybthat drafted the specification did not tievit to any product nor is their any meaningful certification process that say; you either pass this test or you can't call it epub. Such a test must by definition require ecactly the same performance on all certified products. (DVDs are supposed to play the same way on all DVD players regardless of what code lies underneath; epubs display differently pretty much everywhere.)

This is not meaningful, as variation is inevitable. For example, assume your ePub file contains full color cover and interior illustrations. Your eInk based reader doesn't do color. Color images will be rendered as 16 shade gray scale. Adobe Digital Editions on the PC does do color, because the PC hardware does. So you now have a fundamental difference in the way the file will display, based on limitations in the underlying hardware.

This is not something any certification process such as you advocate can address.

A "standard" without a certification process and penalties for incomplete/improper compliance is just a specification in disguise. Without a meaningful certification process the ebook products that people can buy will follow the defacto standard set by adobe just as in the early days of PCs the standard for PC compatibility wasn't MS-DOS, but rather Lotus 1-2-3 and Flight simulator. If it ran those, it was deemed PC compatible and it stayed that way until MS finally asserted their control with MS-DOS 5. ("DOS ain't done until Lotus won't run", says the legend.)

So it's a spec in disguise. So what? From our point of view, the idea is that it's a spec everyone can write to and support. I expect an ePub file to be readable on any device that supports the ePub format, and I expect "graceful degradation", such as a decent grey scale conversion of color images in the file if my device doesn't support color.

The market does the policing here. If the informal test is "It looks as expected in Adobe Digital Editions", it's my responsibility as a content producer to create ePub files that do. If I am a device manufacturer or software developer, it's my responsibility to make a device or write software that will do the job the same as Adobe Digital Editions to the extent possible, so differences are those imposed by the underlying hardware.

Content that isn't displayable on any specs confirming device, and devices that don't properly conform to the spec will get weeded out soon enough because people won't buy them. The biggest issue with any spec are the gray areas that are open to interpretation as to just what you should do in a particular case. Look at any discussion of the specs for the C and C++ languages, and how various compilers have chosen to implement the specs for good examples of the issues involved.

And no, that informal compatibility test didn't come to an end when Microsoft asserted control in MS-DOS 5.

The issues involved had little to do with MS-DOS and everything to do with hardware. While you technically could do hardware access through the BIOS and MS-DOS, most software vendors wrote directly to the hardware for performance reasons. The informal "runs Lotus and Flight Simulator" test was primarily for video display, and become less relevant as PC manufacturers began making hardware that was compatible, with BIOSes that were likewise. Once upon a time Compaq was the gold standard for IBM-PC compatibility, and could charge a price premium because you could expect it to be compatible with with genuine IBM kit.

MS didn't truly assert dominance until Windows. Windows was multi-tasking, and you pretty much had to do everything through the OS. You couldn't assume, as you could in MS-DOS days, that your program had sole control of the machine and could talk directly to the hardware when it ran. As of Windows NT, the OS became positively surly if programmers tried to bypass it.

(I was around back then, and have fond () memories of when the IBM PC was first becoming popular in corporate America, displacing Apple ][s running VisiCalc, and Lotus 1,2,3 was forcing everyone to upgrade to a whole <gasp!> 640K of RAM to accommodate enormous Lotus spreadsheets.)

Regardless of what the standards body says, in real world terms, adobe controls epub: If it won't display properly in ADE, it isn't "proper" epub in the eyes of the buying public. And since every eReader supporting ePub with DRM uses adobe code, everything else is up the creek; pay adobe its fees or try to convince the customers that the inconsistencies that *will* arise aren't your fault.

Heck, even licensing from adobe won't prevent that; just ask the folks with Hanlin-based readers...

<shrug> So?

It's not in Adobe's interest to play games with the spec. They are a B2B outfit. They make their money licensing stuff like this. They want a spec everyone can adhere to. If someone chooses to bypass them and create their own software to produce or display ePub files, that's not going to kill Adobe. They are betting it will be faster and cheaper for most folks to license their code than to roll their own, and mostly, they'll be right.

And sorry about Hanlin, but simply licensing code from another party doesn't mean I will successfully implement that code on my hardware.
______
Dennis