I recently learned about Cuil, a search engine founded by Google spin off employees. The hype about having the biggest online catalog, outperforming Google any time.
I tried it
Searched for my name, I received one result page with approximately 7 teasers. Over all the page claims to have found 2.806 results (as opposed to Googles 840).
1 Teaser had nothing whatsoever to do with me, the rest was pretty mundane stuff. I could not browse the promised 2.806 results, had to stick to the 6 correct references. Googles results immediately were relevant and pointed to material that referred to me as a person or my work.
Verdict
Cuil is simply not worth the effort (this is why there is no link to the page)
Later I learned that Cuil was seed funded. This explains why there is so much hype about it. They have to earn their money the hard way. Hopefully this is not the start of another dotCom bubble.
Showing posts with label Technology. Show all posts
Showing posts with label Technology. Show all posts
Wednesday, July 30, 2008
Sunday, February 17, 2008
The end of the Domain concept?
Late 1999 I held a presentation about future developments in computer security. By then, there was an overwhelming hipe in firewall installations. During my speech I was asked about my personal opinion about how firewalls will develop in the future.
My response was quite surprising to the audience.
After my presentation a professor of the local university approached me. He congratuated me on the overall speach but commented, that I was completely wrong on my deduction that firewalls would be unnecessary devices in the future.
9 years after
The Dot.Com bubble was building up, Application Service Provisioning was on the verge, it was clear by then that most communication in the future would traverse through three ports only: HTTP/HTTPS and SMTP (well, there still are some more around).
If so, every communication channel would be redirected in the future to use one of these channel (it proved correct as we see large scale spam and web site attacks and only a few successful expliots).
9 years from now
Where's the point?
Systems cannot be protected at the perimeter any more. Protection schemes have to be introduced into every software service and application. With the increasing offerings of Web Services, boundaries between companies vanish (yet the title). Our carefully crafted computer domains will erode. As soon as they are consolidated (after mergers and company consolidations) they will be obsolete.
We have to use services and data across company boundaries. Small companies have to share information in order to withstand the pressure introduced by large multination enterprises.
If so, this raises the question of who has and who owns information (in the form of data).
DRM becomes DARM
What we see in the music industry is an absurde effort to protect rights. DRM, Digital Rights Management (or restriction of rights of the owner) is a technological approach to manifest control over the use of data.
DARM, Data Access Rigths Management (sorry, I did not come across any suitable term so far), will be the next development. What ACLs are to the operating system, DARM will be to information.
DARM will not only cover the rights to access information, but also timing information and environmental parameters that allow for viewing the content (similar to cascaded style sheets on steroids).
With the concept of Service Oriented Architecture carried on, the IT of the company of the future will pretty much look like an encapsulated ISP. Services will be offered to anyone subscribing to it.
My response was quite surprising to the audience.
Firewalls and Virus protection are as protective as a perforated condom works for saver sex.The audience was not happy. They came for support in their next major investment. Speakers before and after me were praising the techology as a panacea for any sorts of protection.
After my presentation a professor of the local university approached me. He congratuated me on the overall speach but commented, that I was completely wrong on my deduction that firewalls would be unnecessary devices in the future.
9 years after
The Dot.Com bubble was building up, Application Service Provisioning was on the verge, it was clear by then that most communication in the future would traverse through three ports only: HTTP/HTTPS and SMTP (well, there still are some more around).
If so, every communication channel would be redirected in the future to use one of these channel (it proved correct as we see large scale spam and web site attacks and only a few successful expliots).
9 years from now
Where's the point?
Systems cannot be protected at the perimeter any more. Protection schemes have to be introduced into every software service and application. With the increasing offerings of Web Services, boundaries between companies vanish (yet the title). Our carefully crafted computer domains will erode. As soon as they are consolidated (after mergers and company consolidations) they will be obsolete.
We have to use services and data across company boundaries. Small companies have to share information in order to withstand the pressure introduced by large multination enterprises.
If so, this raises the question of who has and who owns information (in the form of data).
DRM becomes DARM
What we see in the music industry is an absurde effort to protect rights. DRM, Digital Rights Management (or restriction of rights of the owner) is a technological approach to manifest control over the use of data.
DARM, Data Access Rigths Management (sorry, I did not come across any suitable term so far), will be the next development. What ACLs are to the operating system, DARM will be to information.
DARM will not only cover the rights to access information, but also timing information and environmental parameters that allow for viewing the content (similar to cascaded style sheets on steroids).
In this future, the concept of computer domains makes no sense.Notebook users (especially those using Microsoft Windows) have trouble traversing domains. Trusts on the domain level have to be set up or the user will not be able to access any peripherals or services provided by the local domain.
With the concept of Service Oriented Architecture carried on, the IT of the company of the future will pretty much look like an encapsulated ISP. Services will be offered to anyone subscribing to it.
- Questions about ownership of data and services have to answered.
- Issues of multi cultural access and presentation have to be solved.
- Problems relating to the timely validity will arise.
- Censorship and circumvention of it will be on the agenda.
Thursday, April 26, 2007
Krieg der offenen Dateiformate
ODF vs. OpenXML
In seinem Blog [1] behauptet Brian Jones, Office Program Manager bei Microsoft, dass der Krieg der offenen Dateiformate beendet sei. Grund sei die Freigabe einer speziellen Version von OpenOffice durch Novell, welche Daten in Microsofts neuem Fileformat OpenXML lesen und schreiben kann. Tatsächlich handelt es sich nur um einen eigenständigen Konverter [2], der OpenOffice Writer Dokumente in Word 2007 Dokumente umwandelt. Ist der Krieg der offenen Dateiformate tatsächlich beendet?
Bisher speicherte Anwendungssoftware ihre Daten als ein Abbild des Hauptspeichers auf Festplatten. Dieser Vorgang ist schnell und effizient, langwierige Übersetzungen der Datenstrukturen unterbleiben. Er ist aber auch fehleranfällig. Speicherabbilder enthalten Querverweise und Verkettungen. Ein fehlerhafter Wert beim Datentransfer führt zu unbrauchbaren Gesamtergebnissen.
Im Lauf der Jahre wurden die internen Datenstrukturen immer komplizierter. Anfänglich bestanden Dokumente nur aus Zeichenketten. Später kamen Textformatierungen, Schriftarten, eingelagerte Bilder und Tabellen hinzu. Mit steigender Komplexität stieg der Platzbedarf auf Datenträgern und die Dauer, welche die Software zum Einlesen und Abspeichern benötigt. Mit jeder neuen Version entstanden Unverträglichkeiten mit den Daten der Vorgängerversionen. Die Datenübernahme anderer Hersteller wurde durch fehlende oder ungenügende Dokumentation der Dateiformate behindert. Besonders der Marktführer Microsoft verteidigte seine Position vehement, sowohl durch laufende Änderung der Dateiformate, als auch durch Verbot von Rückübersetzungen. So entwickelten Alternativanbieter Import- und Exportfilter welche rudimentären Dokumentenaustausch ermöglichen. Um das ursprüngliche Erscheinungsbild wiederherzustellen sind jedoch aufwendige manuelle Nacharbeiten notwendig.
Wozu neue Dateiformate?
Längerfristig entstanden Probleme beim Zugriff, bei der Lesbarkeit, Nutzbarkeit und Vergleichbarkeit von Dokumenten. Besonders im Bereich öffentlicher Verwaltungen besteht Bedarf, auf alte und historische Dokumente uneingeschränkt zugreifen zu können. Über Jahrhunderte wurde Papier als Informationsspeicher erfolgreich genutzt. Ein Ersatz durch elektronische Datenverarbeitung kann nur dann erfolgen, wenn die Nachhaltigkeit, Vertraulichkeit, Sicherheit und Datenintegrität gewährleistet werden kann.
Mit herkömmlichen Dateiformaten sind derartige Anforderungen nicht abzudecken. Parallel zum wachsenden Bedarf aus dem öffentlichen Sektor wuchs der Kostendruck in Unternehmen, hervorgerufen durch Unverträglichkeiten bei den Dateiformaten und daraus resultierender Ineffizienz der Arbeitsabläufe.
Langzeittauglichkeit gefordert
Führende Softwarefirmen entwickelten im Rahmen des OASIS Konsortiums [3] einen offenen Dokumentenstandard, der die gravierendsten Probleme wie Langfristigkeit, Lesbarkeit und Fehlerresistenz lösen soll. Das Open Document Format (ODF) [4] versprach ein Ende bisheriger Inkompatibilitäten zwischen Dateiformaten, sowohl versions- als auch herstellerübergreifend. Mit über 700 Seiten ist der Standard umfassend und für zukünftige Erweiterungen offen.
Öffentliche Verwaltungen und Institutionen erkannten das Potential des neuen Standards. Neben einigen Bundesstaaten der USA definierten vor allem Länder aus Südamerika und Europa sowie einige asiatische Länder ODF als verbindlichen Dokumentenstandard im Parteienverkehr und der internen Abläufe. Spätestens mit der Ankündigung des Department of Defence (DoD) im Jahr 2003, verstärkt Open Source Software und offene Dokumentenstandards zu nutzen, reagierte Microsoft auf diese Entwicklungen.
Nicht nur Mittel zur Datenspeicherung
Microsoft verfügt über einen hohen Marktanteil im Bereich des Basisbetriebssystems, der Standard-Anwendungssoftware und auch bei den Dokumentenformaten. Insbesondere die Dokumentenformate helfen Microsoft, Updatezyklen bei der Standardsoftware und den Betriebssystemen massgeblich zu steuern. Unverträglichkeiten zwischen den Versionen führen mittelfristig dazu, dass Firmen über ihre Aussenkontakte zu einem Update gezwungen sind, wenn sie nicht den elektronischen Anschluss an ihre Partner verpassen wollen. Automatisierte Systemnachbesserungen erleichtern es Microsoft, diesen Zwang nach belieben zu verstärken. Eine nachhaltige Neuorientierung grosser Kunden wie dem DoD gefährdet die Marktposition von Microsoft in Ihren Grundfesten.
Diese Abkehr war nur durch die Bereitstellung offener Standards im Bereich der Dateiformate zu verhindern. ODF als Dateiformat kommt aus marktpolitischen Überlegungen für Microsoft nicht in Frage. So wurde 2005 im Rahmen der ECMA ein neuer Standard ausgearbeitet: ECMA-376 oder Office OpenXML [5,6] wurde am 7. Dezember 2006 trotz zahlreicher technischer Einsprüche [7] durchgesetzt. Dieser Standard umfasst derzeit mehr als 6.500 Seiten, zahlreiche XML Schemaspezifikationen und deckt die Office-Anwendungen Word, Excel, Powerpoint und Access ab [8,9].
(Ironie am Rande: In seiner Proposalpräsentation vor der ECMA [10] verweist Brian Jones auf ein Dokument der EU zum Thema Open Document Standards und Vorteile der Nutzung. Das Originaldokument [11] beschreibt allerdings diese Vorteile unter eindeutigem Bezug auf ODF)
Was können die neuen Formate ...
ODF und OpenXML sind technisch sehr ähnlich. Sie speichern verschiedene Bestandteile der Dokumente als XML Dateien in ZIP Archiv ab. ZIP ist ein anerkannter und weit verbreiteter Kompressionsalgorithmus. XML ist eine erweiterbare Beschreibungssprache für hierarchisch gliederbare Datenbestände. XML Dateien sind zwar grösser als binäre Dateiformate gleichen Inhalts, lassen sich aber aufgrund der hohen Informationsredundanz besser komprimieren. Die komprimierten Archive können schneller auf Datenträger geschrieben und von dort gelesen werden. Dateiinhalte werden nicht unmittelbar in den Arbeitsspeicher übernommen, sondern zuerst analysiert und in maschinenverwertbare Form umgewandelt. Die Dateiformate sind fehlerresistenter als Ihre Vorgänger. Beide Dateiformate können aufgrund ihrer offenen Struktur automatisiert nachbearbeitet werden.
ODF und OpenXML erlauben die Einbindung binärer Informationsfragmente sowie Script- und Makrosprachen. Das führt zu neuen Sicherheitsrisiken. Keines der beiden Formate bietet hinreichenden integrierten Schutz vor ungewollten Änderungen von Dateninhalten. Sie bieten genügend Angriffsfläche zum Einschleusen von Schadcode. Es bleibt den Anwendungsprogrammen überlassen, dies zu verhindern. Microsoft Office prüft anhand der Erweiterung des Dateinamens, ob der Aufruf von Makros erlaubt ist. Dieser Schutz ist allerdings leicht zu umgehen und suggeriert daher eine nicht vorhandene Sicherheit.
Beide Formate gewährleisten den längerfristigen Zugriff auf Daten. In der Darstellung hängen Sie - wie ihre traditionellen Vorgänger - von zahlreichen externen Faktoren ab. Das optisch gleiche Erscheinungsbild kann mit den aktuellen Standards nicht garantiert werden.
... und wo unterscheiden sie sich?
ODF Dateien sind kleiner als ihr OpenXML Pendant. ODF speichert Inhalte gemeinsam mit der Formatierung. OpenXML trennt konsequent Text von der Formatierung. Das ist technisch sauberer und führt erstaunlicherweise nicht zu längeren Ladezeiten. Microsoft behält sich die Option vor, grössere Dateien auch in einem proprietären Format einzubinden, um eventuelle Engpässe in der Performance zu umgehen. Hier sind Inkompatibilitäten vorprogrammiert.
OpenXML greift nicht auf bestehende Standards zurück. Unter anderem wurden neue Standards für Grafiken, Texten, Tabellen, mathematischen Formel, Länder- und Farbcodes definiert. Damit wurde die Spezifikation aufgebläht. In der Umsetzung erhöht das die Fehleranfälligkeit von Anwendungssoftware und Formatkonvertern. ODF setzt in allen Bereichen auf etablierte Standards wie SVG, XML, mathML und standardisierte ISO-Codes.
Wie frei ist „Frei“?
ODF und OpenXML sind lizensierbare Standards, deren Nutzung unentgeltlich ist. ODF kann im Rahmen der Lizenzen durch Dritte ergänzt werden. Das Open Document White Paper verweist auf 9 Referenzimplementation [12]. Zu einigen davon ist der Quellcode verfügbar. Dem gegenüber verweist Microsoft nur auf eine Referenzimplementation, Office 2007, welche nicht quelloffen ist.
Ein Gutachten bestätigt ODF patentrechtliche Unbedenklichkeit. Sun, Hauptzulieferer zum ODF-Standard, hat einen ergänzenden Forderungsverzicht abgegeben. Der Ausstieg einzelner Mitglieder aus dem OASIS Konsortium ist klar geregelt, sodass in Zukunft Ansprüche von Altmitgliedern nicht zu erwarten sind. Eventuell zukünftig auftauchende Forderungen aus Patentrechten werden nicht vollständig ausgeschlossen. OASIS bestätigt dieses marginale Restrisiko, sieht aber selbst keinen Lösungsansatz.
Microsoft stellt die Nutzung von OpenXML jedermann frei. Microsoft verweist auf seine Patente im OpenXML Standard, gibt allerdings auch einen schriftlichen Klagsverzicht auf seiner Website ab. Dieser erschöpft sich auf die im Standard berührten Technologien und Patente. Patente, die von der ordnungsgemässen Umsetzung der OpenXML-Spezifikation in Anwendungssoftware berührt werden, sowie eventuelle Patente von Drittherstellern sind von dieser Freistellung nicht betroffen. Insbesondere bei der Einbindung in Anwendungssoftware sehen Rechtsexperten ein nicht unbeträchtliches Rechtsrisiko welches Microsoft nicht entkräftet.
Sowohl ODF als auch OpenXML sind derzeit sowohl frei zugänglich, frei nutzbar, frei von Kosten sowie frei von patentrechtlichen Einschränkungen. ODF ist für Softwareentwickler leichter zugänglich. Der überschaubare Umfang der Spezifikationen erlaubt wirtschaftliches Einarbeiten in das Thema. OpenXML mit über 6.500 Seiten und zahlreichen Schematas drängt sich dagegen dem Interessenten nicht unmittelbar auf.
Attraktiv für den öffentlichen Bereich
Öffentliche Verwaltungen und Regierungen fordern die Nutzung offener Dateiformate aus zwei Hauptgründen:
1. soll die langfristige Nutzbarkeit auch auf unterschiedlichsten EDV-Systemen gewährleistet sein. Diese Forderung wird hauptsächlich in Ämtern und Behörden gestellt.
2. soll die starke Abhängigkeit von Softwareanbietern reduziert und - wenn möglich - lokales Know-how genutzt werden. Diese Forderung stellen vornehmlich Regierungen.
Hier hat ODF einen deutlichen Vorsprung. Das Format existiert bereits seit längerer Zeit, ist einige Male implementiert und in quelloffener Form zugänglich. Der Standard wird sowohl von einigen grossen Softwareherstellern als auch von einer umfangreichen Entwicklergemeinschaft unterstützt. ODF hat noch einige Einschränkungen, die den Einsatz im öffentlichen Bereich behindern. Die langfristige Erweiterbarkeit ist noch nicht nachgewiesen. OpenXML kann auf keine substantiellen Vorteile verweisen, welche einen Einsatz zwingend notwendig machen würden. Allerdings besitzt Microsoft eine breite installierte Basis, auf die das Unternehmen starken Einfluss über seine automatisierten Updates ausüben kann.
Öffentliche Stellen können bis zu einer endgültigen Lösung der offenen Probleme die ersten Schritte in Richtung Automatisierung gehen. Notwendige Ergänzungen lassen sich in weiteren Phasen der Umsetzung nachziehen.
Attraktiv für Unternehmen?
Unternehmen agieren in kurzfristigeren Innovationszyklen. Nur ein geringer Teil der betriebsnotwendigen Informationen haben langfristige Relevanz (Verträge, Finanzinformationen) und müssen entsprechend archiviert und gewartet werden. Der Rest der Arbeitsdokumente hat eine geringe Halbwertszeit.
Eine grundsätzliche Entscheidung bezüglich eines Dateiformates ist nur dann möglich, wenn die Entscheidung bezüglich alternativer Anwendungssoftware zur Disposition steht. Das Erstellen von ODF Dateien mit Microsoft Office (Word, Excel, Powerpoint, Access) ist heute nicht möglich und zukünftig nicht absehbar. Umgekehrt ist das Erstellen von OpenXML Dateien aus alternativer Anwendungssoftware derzeit nur eingeschränkt möglich. Da Microsofts Anwendungsprogramme in Unternehmen besonders stark verbreitet sind, ist der Einsatz von OpenXML zumindest dort vorhersehbar.
Bekannte Migrationsprojekte, wie jenes der Stadt München oder der Lufthansa, sind weitgehend von strategischen, politischen oder ideellen Motiven geleitet. Wirtschaftliche Vorteile bei der Betrachtung der Gesamtkosten sind marginal oder nicht vorhanden. Wer sich letztlich durchsetzen wird - öffentliche Verwaltungen und Regierungen die ODF bevorzugen oder Unternehmen die Microsoft mit OpenXML nutzen - ist derzeit nicht prognostizierbar.
Der Krieg der offenen Dateiformate ist demnach noch nicht beendet. Wir erleben bestenfalls eine kurzfristigen Waffenstillstand.
Bibliographie:
[1] Blog Brian Jones
[2] Novell OpenXML Translator
[3] OASIS Gründungsmitglieder
[4] Open Document for Office Applications
[5] ECMA-376 - Office OpenXML
[6] Office OpenXML Fact Sheet
[7] Objections to JTC-1 Fast-Track Processing of the Ecma 376 Specification v. 0.1, 27.1.2007
[8] ECMA-376 OpenXML White Paper
[9] Introducing the Office (2007) Open XML File Formats
[10] Start of TC45: Presentation to GA
[11] TAC approval on conclusions and recommendations on open document formats
[12] Open by Design, ODF White Paper
In seinem Blog [1] behauptet Brian Jones, Office Program Manager bei Microsoft, dass der Krieg der offenen Dateiformate beendet sei. Grund sei die Freigabe einer speziellen Version von OpenOffice durch Novell, welche Daten in Microsofts neuem Fileformat OpenXML lesen und schreiben kann. Tatsächlich handelt es sich nur um einen eigenständigen Konverter [2], der OpenOffice Writer Dokumente in Word 2007 Dokumente umwandelt. Ist der Krieg der offenen Dateiformate tatsächlich beendet?
Bisher speicherte Anwendungssoftware ihre Daten als ein Abbild des Hauptspeichers auf Festplatten. Dieser Vorgang ist schnell und effizient, langwierige Übersetzungen der Datenstrukturen unterbleiben. Er ist aber auch fehleranfällig. Speicherabbilder enthalten Querverweise und Verkettungen. Ein fehlerhafter Wert beim Datentransfer führt zu unbrauchbaren Gesamtergebnissen.
Im Lauf der Jahre wurden die internen Datenstrukturen immer komplizierter. Anfänglich bestanden Dokumente nur aus Zeichenketten. Später kamen Textformatierungen, Schriftarten, eingelagerte Bilder und Tabellen hinzu. Mit steigender Komplexität stieg der Platzbedarf auf Datenträgern und die Dauer, welche die Software zum Einlesen und Abspeichern benötigt. Mit jeder neuen Version entstanden Unverträglichkeiten mit den Daten der Vorgängerversionen. Die Datenübernahme anderer Hersteller wurde durch fehlende oder ungenügende Dokumentation der Dateiformate behindert. Besonders der Marktführer Microsoft verteidigte seine Position vehement, sowohl durch laufende Änderung der Dateiformate, als auch durch Verbot von Rückübersetzungen. So entwickelten Alternativanbieter Import- und Exportfilter welche rudimentären Dokumentenaustausch ermöglichen. Um das ursprüngliche Erscheinungsbild wiederherzustellen sind jedoch aufwendige manuelle Nacharbeiten notwendig.
Wozu neue Dateiformate?
Längerfristig entstanden Probleme beim Zugriff, bei der Lesbarkeit, Nutzbarkeit und Vergleichbarkeit von Dokumenten. Besonders im Bereich öffentlicher Verwaltungen besteht Bedarf, auf alte und historische Dokumente uneingeschränkt zugreifen zu können. Über Jahrhunderte wurde Papier als Informationsspeicher erfolgreich genutzt. Ein Ersatz durch elektronische Datenverarbeitung kann nur dann erfolgen, wenn die Nachhaltigkeit, Vertraulichkeit, Sicherheit und Datenintegrität gewährleistet werden kann.
Mit herkömmlichen Dateiformaten sind derartige Anforderungen nicht abzudecken. Parallel zum wachsenden Bedarf aus dem öffentlichen Sektor wuchs der Kostendruck in Unternehmen, hervorgerufen durch Unverträglichkeiten bei den Dateiformaten und daraus resultierender Ineffizienz der Arbeitsabläufe.
Langzeittauglichkeit gefordert
Führende Softwarefirmen entwickelten im Rahmen des OASIS Konsortiums [3] einen offenen Dokumentenstandard, der die gravierendsten Probleme wie Langfristigkeit, Lesbarkeit und Fehlerresistenz lösen soll. Das Open Document Format (ODF) [4] versprach ein Ende bisheriger Inkompatibilitäten zwischen Dateiformaten, sowohl versions- als auch herstellerübergreifend. Mit über 700 Seiten ist der Standard umfassend und für zukünftige Erweiterungen offen.
Öffentliche Verwaltungen und Institutionen erkannten das Potential des neuen Standards. Neben einigen Bundesstaaten der USA definierten vor allem Länder aus Südamerika und Europa sowie einige asiatische Länder ODF als verbindlichen Dokumentenstandard im Parteienverkehr und der internen Abläufe. Spätestens mit der Ankündigung des Department of Defence (DoD) im Jahr 2003, verstärkt Open Source Software und offene Dokumentenstandards zu nutzen, reagierte Microsoft auf diese Entwicklungen.
Nicht nur Mittel zur Datenspeicherung
Microsoft verfügt über einen hohen Marktanteil im Bereich des Basisbetriebssystems, der Standard-Anwendungssoftware und auch bei den Dokumentenformaten. Insbesondere die Dokumentenformate helfen Microsoft, Updatezyklen bei der Standardsoftware und den Betriebssystemen massgeblich zu steuern. Unverträglichkeiten zwischen den Versionen führen mittelfristig dazu, dass Firmen über ihre Aussenkontakte zu einem Update gezwungen sind, wenn sie nicht den elektronischen Anschluss an ihre Partner verpassen wollen. Automatisierte Systemnachbesserungen erleichtern es Microsoft, diesen Zwang nach belieben zu verstärken. Eine nachhaltige Neuorientierung grosser Kunden wie dem DoD gefährdet die Marktposition von Microsoft in Ihren Grundfesten.
Diese Abkehr war nur durch die Bereitstellung offener Standards im Bereich der Dateiformate zu verhindern. ODF als Dateiformat kommt aus marktpolitischen Überlegungen für Microsoft nicht in Frage. So wurde 2005 im Rahmen der ECMA ein neuer Standard ausgearbeitet: ECMA-376 oder Office OpenXML [5,6] wurde am 7. Dezember 2006 trotz zahlreicher technischer Einsprüche [7] durchgesetzt. Dieser Standard umfasst derzeit mehr als 6.500 Seiten, zahlreiche XML Schemaspezifikationen und deckt die Office-Anwendungen Word, Excel, Powerpoint und Access ab [8,9].
(Ironie am Rande: In seiner Proposalpräsentation vor der ECMA [10] verweist Brian Jones auf ein Dokument der EU zum Thema Open Document Standards und Vorteile der Nutzung. Das Originaldokument [11] beschreibt allerdings diese Vorteile unter eindeutigem Bezug auf ODF)
Was können die neuen Formate ...
ODF und OpenXML sind technisch sehr ähnlich. Sie speichern verschiedene Bestandteile der Dokumente als XML Dateien in ZIP Archiv ab. ZIP ist ein anerkannter und weit verbreiteter Kompressionsalgorithmus. XML ist eine erweiterbare Beschreibungssprache für hierarchisch gliederbare Datenbestände. XML Dateien sind zwar grösser als binäre Dateiformate gleichen Inhalts, lassen sich aber aufgrund der hohen Informationsredundanz besser komprimieren. Die komprimierten Archive können schneller auf Datenträger geschrieben und von dort gelesen werden. Dateiinhalte werden nicht unmittelbar in den Arbeitsspeicher übernommen, sondern zuerst analysiert und in maschinenverwertbare Form umgewandelt. Die Dateiformate sind fehlerresistenter als Ihre Vorgänger. Beide Dateiformate können aufgrund ihrer offenen Struktur automatisiert nachbearbeitet werden.ODF und OpenXML erlauben die Einbindung binärer Informationsfragmente sowie Script- und Makrosprachen. Das führt zu neuen Sicherheitsrisiken. Keines der beiden Formate bietet hinreichenden integrierten Schutz vor ungewollten Änderungen von Dateninhalten. Sie bieten genügend Angriffsfläche zum Einschleusen von Schadcode. Es bleibt den Anwendungsprogrammen überlassen, dies zu verhindern. Microsoft Office prüft anhand der Erweiterung des Dateinamens, ob der Aufruf von Makros erlaubt ist. Dieser Schutz ist allerdings leicht zu umgehen und suggeriert daher eine nicht vorhandene Sicherheit.
Beide Formate gewährleisten den längerfristigen Zugriff auf Daten. In der Darstellung hängen Sie - wie ihre traditionellen Vorgänger - von zahlreichen externen Faktoren ab. Das optisch gleiche Erscheinungsbild kann mit den aktuellen Standards nicht garantiert werden.
... und wo unterscheiden sie sich?
ODF Dateien sind kleiner als ihr OpenXML Pendant. ODF speichert Inhalte gemeinsam mit der Formatierung. OpenXML trennt konsequent Text von der Formatierung. Das ist technisch sauberer und führt erstaunlicherweise nicht zu längeren Ladezeiten. Microsoft behält sich die Option vor, grössere Dateien auch in einem proprietären Format einzubinden, um eventuelle Engpässe in der Performance zu umgehen. Hier sind Inkompatibilitäten vorprogrammiert.
OpenXML greift nicht auf bestehende Standards zurück. Unter anderem wurden neue Standards für Grafiken, Texten, Tabellen, mathematischen Formel, Länder- und Farbcodes definiert. Damit wurde die Spezifikation aufgebläht. In der Umsetzung erhöht das die Fehleranfälligkeit von Anwendungssoftware und Formatkonvertern. ODF setzt in allen Bereichen auf etablierte Standards wie SVG, XML, mathML und standardisierte ISO-Codes.
Wie frei ist „Frei“?
ODF und OpenXML sind lizensierbare Standards, deren Nutzung unentgeltlich ist. ODF kann im Rahmen der Lizenzen durch Dritte ergänzt werden. Das Open Document White Paper verweist auf 9 Referenzimplementation [12]. Zu einigen davon ist der Quellcode verfügbar. Dem gegenüber verweist Microsoft nur auf eine Referenzimplementation, Office 2007, welche nicht quelloffen ist.
Ein Gutachten bestätigt ODF patentrechtliche Unbedenklichkeit. Sun, Hauptzulieferer zum ODF-Standard, hat einen ergänzenden Forderungsverzicht abgegeben. Der Ausstieg einzelner Mitglieder aus dem OASIS Konsortium ist klar geregelt, sodass in Zukunft Ansprüche von Altmitgliedern nicht zu erwarten sind. Eventuell zukünftig auftauchende Forderungen aus Patentrechten werden nicht vollständig ausgeschlossen. OASIS bestätigt dieses marginale Restrisiko, sieht aber selbst keinen Lösungsansatz.
Microsoft stellt die Nutzung von OpenXML jedermann frei. Microsoft verweist auf seine Patente im OpenXML Standard, gibt allerdings auch einen schriftlichen Klagsverzicht auf seiner Website ab. Dieser erschöpft sich auf die im Standard berührten Technologien und Patente. Patente, die von der ordnungsgemässen Umsetzung der OpenXML-Spezifikation in Anwendungssoftware berührt werden, sowie eventuelle Patente von Drittherstellern sind von dieser Freistellung nicht betroffen. Insbesondere bei der Einbindung in Anwendungssoftware sehen Rechtsexperten ein nicht unbeträchtliches Rechtsrisiko welches Microsoft nicht entkräftet.
Sowohl ODF als auch OpenXML sind derzeit sowohl frei zugänglich, frei nutzbar, frei von Kosten sowie frei von patentrechtlichen Einschränkungen. ODF ist für Softwareentwickler leichter zugänglich. Der überschaubare Umfang der Spezifikationen erlaubt wirtschaftliches Einarbeiten in das Thema. OpenXML mit über 6.500 Seiten und zahlreichen Schematas drängt sich dagegen dem Interessenten nicht unmittelbar auf.
Attraktiv für den öffentlichen Bereich
Öffentliche Verwaltungen und Regierungen fordern die Nutzung offener Dateiformate aus zwei Hauptgründen:
1. soll die langfristige Nutzbarkeit auch auf unterschiedlichsten EDV-Systemen gewährleistet sein. Diese Forderung wird hauptsächlich in Ämtern und Behörden gestellt.
2. soll die starke Abhängigkeit von Softwareanbietern reduziert und - wenn möglich - lokales Know-how genutzt werden. Diese Forderung stellen vornehmlich Regierungen.
Hier hat ODF einen deutlichen Vorsprung. Das Format existiert bereits seit längerer Zeit, ist einige Male implementiert und in quelloffener Form zugänglich. Der Standard wird sowohl von einigen grossen Softwareherstellern als auch von einer umfangreichen Entwicklergemeinschaft unterstützt. ODF hat noch einige Einschränkungen, die den Einsatz im öffentlichen Bereich behindern. Die langfristige Erweiterbarkeit ist noch nicht nachgewiesen. OpenXML kann auf keine substantiellen Vorteile verweisen, welche einen Einsatz zwingend notwendig machen würden. Allerdings besitzt Microsoft eine breite installierte Basis, auf die das Unternehmen starken Einfluss über seine automatisierten Updates ausüben kann.
Öffentliche Stellen können bis zu einer endgültigen Lösung der offenen Probleme die ersten Schritte in Richtung Automatisierung gehen. Notwendige Ergänzungen lassen sich in weiteren Phasen der Umsetzung nachziehen.
Attraktiv für Unternehmen?
Unternehmen agieren in kurzfristigeren Innovationszyklen. Nur ein geringer Teil der betriebsnotwendigen Informationen haben langfristige Relevanz (Verträge, Finanzinformationen) und müssen entsprechend archiviert und gewartet werden. Der Rest der Arbeitsdokumente hat eine geringe Halbwertszeit.
Eine grundsätzliche Entscheidung bezüglich eines Dateiformates ist nur dann möglich, wenn die Entscheidung bezüglich alternativer Anwendungssoftware zur Disposition steht. Das Erstellen von ODF Dateien mit Microsoft Office (Word, Excel, Powerpoint, Access) ist heute nicht möglich und zukünftig nicht absehbar. Umgekehrt ist das Erstellen von OpenXML Dateien aus alternativer Anwendungssoftware derzeit nur eingeschränkt möglich. Da Microsofts Anwendungsprogramme in Unternehmen besonders stark verbreitet sind, ist der Einsatz von OpenXML zumindest dort vorhersehbar.
Bekannte Migrationsprojekte, wie jenes der Stadt München oder der Lufthansa, sind weitgehend von strategischen, politischen oder ideellen Motiven geleitet. Wirtschaftliche Vorteile bei der Betrachtung der Gesamtkosten sind marginal oder nicht vorhanden. Wer sich letztlich durchsetzen wird - öffentliche Verwaltungen und Regierungen die ODF bevorzugen oder Unternehmen die Microsoft mit OpenXML nutzen - ist derzeit nicht prognostizierbar.
Der Krieg der offenen Dateiformate ist demnach noch nicht beendet. Wir erleben bestenfalls eine kurzfristigen Waffenstillstand.
Bibliographie:
[1] Blog Brian Jones
[2] Novell OpenXML Translator
[3] OASIS Gründungsmitglieder
[4] Open Document for Office Applications
[5] ECMA-376 - Office OpenXML
[6] Office OpenXML Fact Sheet
[7] Objections to JTC-1 Fast-Track Processing of the Ecma 376 Specification v. 0.1, 27.1.2007
[8] ECMA-376 OpenXML White Paper
[9] Introducing the Office (2007) Open XML File Formats
[10] Start of TC45: Presentation to GA
[11] TAC approval on conclusions and recommendations on open document formats
[12] Open by Design, ODF White Paper
Sunday, March 04, 2007
The future of video
Currently, we are migrating our workstations from Windows to Linux. While the basic stuff works perfectly fine, we run into trouble when dealing with music and video.
Especially video.
Our video collection does not work under Linux.
While playing videos under Windows is not an easy feat, playing them under Linux provides insight into a lot of things. Unfortunately, videos are not among them.
Let's summarize:
Videos are stored in container files. To play them, codecs and decoders are required. Some, like MPEG2 and MPEG4 are straight forward, some, like DivX, XVid, H264 are embedded in AVI files.
Under Windows, you install codecs, the installer hooks them into the search path of any installed media player. OK, some honor these paths, some don't. Sometimes, helper applications like Explorer get confused and crash. But low and behold, it works pretty well.
Under Linux, you need graphics libraries, that have library plug-ins. If you ever tried to make ends meet with gstreamer, you know what I am talking about.
My suggestion
Here is a proposal of how video streams could be encoded in order to eliminate the codec problem and thus make video handling user friendly.
All video is encoded using an video and audio encoder. Mixtures are possible and exist.
A new file format could accommodate 2 parts: One, the decoder codec and two, the film itself. The codec would be extracted by a generic decoding engine and used to decrypt the film stream. The player would be a generic codec interpreter that allows for platform independent decoder plug-ins to be hooked in.
None of the above mentioned technologies is new. Platform independent plug-ins are reality in Mozilla driven XUL tools. Piggyback codecs can be attached to the video stream. Interpretation engines can both be Python and JavaScript.
This mechanism would even allow for commercial content, as the codecs may well be connected to payment systems.
I haven't given this a deeper thought. Maybe my tweaking with Linux will take me to deeper insights and eventually make me mad enough to write a prototype.
Especially video.
Our video collection does not work under Linux.
While playing videos under Windows is not an easy feat, playing them under Linux provides insight into a lot of things. Unfortunately, videos are not among them.
Let's summarize:
Videos are stored in container files. To play them, codecs and decoders are required. Some, like MPEG2 and MPEG4 are straight forward, some, like DivX, XVid, H264 are embedded in AVI files.
Under Windows, you install codecs, the installer hooks them into the search path of any installed media player. OK, some honor these paths, some don't. Sometimes, helper applications like Explorer get confused and crash. But low and behold, it works pretty well.
Under Linux, you need graphics libraries, that have library plug-ins. If you ever tried to make ends meet with gstreamer, you know what I am talking about.
My suggestion
Here is a proposal of how video streams could be encoded in order to eliminate the codec problem and thus make video handling user friendly.
All video is encoded using an video and audio encoder. Mixtures are possible and exist.
A new file format could accommodate 2 parts: One, the decoder codec and two, the film itself. The codec would be extracted by a generic decoding engine and used to decrypt the film stream. The player would be a generic codec interpreter that allows for platform independent decoder plug-ins to be hooked in.
None of the above mentioned technologies is new. Platform independent plug-ins are reality in Mozilla driven XUL tools. Piggyback codecs can be attached to the video stream. Interpretation engines can both be Python and JavaScript.
This mechanism would even allow for commercial content, as the codecs may well be connected to payment systems.
I haven't given this a deeper thought. Maybe my tweaking with Linux will take me to deeper insights and eventually make me mad enough to write a prototype.
Tuesday, January 16, 2007
Python demystified?
Four years ago I was asked to troubleshoot a project under tight schedule and budget. The team had committed itself to finish an ASP application within 2 years. When I was called, there were only 4 month to the deadline.
I agreed to manage the team under the condition that 2 out of 3 parts be substituted by standard OTS componenten (who needs to develop their own database or browser) and efforts being concentrated on the core functionality.
My proposal was rejected. The project team was confident that using Python programming language would give them an advantage to finish on time and budget.
Later I learned that the project failed and the company went out of business.
My argument then was that Python was not to be compared to C# or Java in efficiency. More so, no real libraries exist.
I was right about the potential of Python as a tool to finish in time.
However I was wrong about the true reason why Python has not gained momentum and probably will not in the future as Java and C# had.
Recent occupation with the subject led me to a different opinion.
1. C# is easy to use and convenient for writing software. However, C#'s strong typing requires programmers to define in advance what to do. Even with refactoring tools and support for generics changes in structure and data definition can cause headache.
Python (as JavaScript) offer weak typing. Objects can be of any type, programmers don't have to worry in advance what they have to handle. Python as opposed to JavaScript has a tight syntax an object declaration (var i, I know its var, so why do I have to state it?)
There are many more advantages to the Python language. Some of them are:
Going from here, I would prefer Python to any language any day.
2. In the early days of Java, everyone wrote their own IDE. This was possible because Java offered AWT a platform independent graphics subsystem. That allowed for many programmers to adopt Java. C# is hosted in the Visual Studio IDE (with a free Express edition available). Even Mono has two prominent IDE's: MonoDevelop and SharpDevelop.
Python offers an outdated IDLE (basically a specialised shell with no charm), ERIC (a bloated QT based environment with an older version of python interpreter), PyDev, a slugish Eclipse plugin, and many more alpha and pre-alpha Editors.
Without any decent IDE (like Netbeans for Java) that allows for graphical programming and UI-design, I strongly doubt that Python will ever gain momentum.
3. There is plenty of introductory books about Java, C# or VB. There are some books around introducing Python. None of the books I reviewed showed how to set up a working python development environment. Maybe its the selection, maybe I am used to skipping chapters on how to get started with other languages. With Python I wasted hours installing, testing and deinstalling IDE's and development tools.
Without a cross platform native or Python based IDE I am pretty sure that Python will be something like Modula 2 in the 70s, ADA in the 80s and LiveScript in the 90s.
Looking back, finishing the project on time was absolutely impossible. Not because of missing power in the language but lack of a powerful IDE.
I agreed to manage the team under the condition that 2 out of 3 parts be substituted by standard OTS componenten (who needs to develop their own database or browser) and efforts being concentrated on the core functionality.
My proposal was rejected. The project team was confident that using Python programming language would give them an advantage to finish on time and budget.
Later I learned that the project failed and the company went out of business.
My argument then was that Python was not to be compared to C# or Java in efficiency. More so, no real libraries exist.
I was right about the potential of Python as a tool to finish in time.
However I was wrong about the true reason why Python has not gained momentum and probably will not in the future as Java and C# had.
Recent occupation with the subject led me to a different opinion.
1. C# is easy to use and convenient for writing software. However, C#'s strong typing requires programmers to define in advance what to do. Even with refactoring tools and support for generics changes in structure and data definition can cause headache.
Python (as JavaScript) offer weak typing. Objects can be of any type, programmers don't have to worry in advance what they have to handle. Python as opposed to JavaScript has a tight syntax an object declaration (var i, I know its var, so why do I have to state it?)
There are many more advantages to the Python language. Some of them are:
- everything is an object,
- strong string operations,
- plethora of external modules,
- integration into host operating systems,
- integration with other programming languages,
- etc. ...
Going from here, I would prefer Python to any language any day.
2. In the early days of Java, everyone wrote their own IDE. This was possible because Java offered AWT a platform independent graphics subsystem. That allowed for many programmers to adopt Java. C# is hosted in the Visual Studio IDE (with a free Express edition available). Even Mono has two prominent IDE's: MonoDevelop and SharpDevelop.
Python offers an outdated IDLE (basically a specialised shell with no charm), ERIC (a bloated QT based environment with an older version of python interpreter), PyDev, a slugish Eclipse plugin, and many more alpha and pre-alpha Editors.
Without any decent IDE (like Netbeans for Java) that allows for graphical programming and UI-design, I strongly doubt that Python will ever gain momentum.
3. There is plenty of introductory books about Java, C# or VB. There are some books around introducing Python. None of the books I reviewed showed how to set up a working python development environment. Maybe its the selection, maybe I am used to skipping chapters on how to get started with other languages. With Python I wasted hours installing, testing and deinstalling IDE's and development tools.
Without a cross platform native or Python based IDE I am pretty sure that Python will be something like Modula 2 in the 70s, ADA in the 80s and LiveScript in the 90s.
Looking back, finishing the project on time was absolutely impossible. Not because of missing power in the language but lack of a powerful IDE.
Wednesday, September 20, 2006
I love .NET, I hate .NET
Recently I developed an ASP.NET application that required access to a database. So far no problem. I have done that several times before and was confident to bring the project to an early end.
During the coding phase I had to make a decision on how to access the database. Usually I would write seperated insert, update and delete procedures in code behind pages. In this particular case it seemed to be appropriate to use an Object DataSource and a GridView control.
So I dropped a GridView into the page and made an new DataSource, choosing the Object DataSource from the wizard. Then I created a class file in the Apps folder to isolate data access there.
I got the records to show in no time and I love .NET for its ease of use.
Next I tried to update records using the Edit functionality of the GridView. This was not a trivial task. First the call to the update member function would throw exceptions at me right, left and center. It turned out (undocumented) that the parameters for the function calls need to have the exact names as the fields in the database table to be altered.
Changing the fields in the GridView works fine, the changed value is forwarded to the update function. However, changing the value in the Row of the Dataset seems to be impossible. Calling the code from a C# program works fine, doing the same out of a ASP.NET class does not work.
I confess, I resorted to the oldfashioned way of updating the database directly to keep the schedule.
I hate .NET for it's non-consistent working and its lack of dokumentation.
During the coding phase I had to make a decision on how to access the database. Usually I would write seperated insert, update and delete procedures in code behind pages. In this particular case it seemed to be appropriate to use an Object DataSource and a GridView control.
So I dropped a GridView into the page and made an new DataSource, choosing the Object DataSource from the wizard. Then I created a class file in the Apps folder to isolate data access there.
I got the records to show in no time and I love .NET for its ease of use.
Next I tried to update records using the Edit functionality of the GridView. This was not a trivial task. First the call to the update member function would throw exceptions at me right, left and center. It turned out (undocumented) that the parameters for the function calls need to have the exact names as the fields in the database table to be altered.
Changing the fields in the GridView works fine, the changed value is forwarded to the update function. However, changing the value in the Row of the Dataset seems to be impossible. Calling the code from a C# program works fine, doing the same out of a ASP.NET class does not work.
I confess, I resorted to the oldfashioned way of updating the database directly to keep the schedule.
I hate .NET for it's non-consistent working and its lack of dokumentation.
Subscribe to:
Posts (Atom)