264 lines
11 KiB
HTML
264 lines
11 KiB
HTML
<?xml version="1.0" encoding="UTF-8" ?>
|
|
|
|
<html>
|
|
<head>
|
|
<title>FSFE - Sechs Fragen an die nationalen Standardisierungsgremien zu
|
|
MS-OOXML</title>
|
|
</head>
|
|
|
|
<body>
|
|
<h1>Sechs Fragen an die nationalen Standardisierungsgremien</h1>
|
|
<center>
|
|
[<a href="msooxml-questions.pdf">Auch als PDF verfügbar (englisch)(28k)</a>]
|
|
</center>
|
|
|
|
<p>
|
|
Die folgenden Fragen befassen sich mit der Anerkennung des
|
|
ECMA/MS-OOXML-Formats als IEC/ISO-Standard. Solange die nationalen
|
|
Standardgremien keine schlüssigen Antworten auf diese Fragen haben,
|
|
sollten sie in der IEC/ISO-Abstimmung mit "Nein" stimmen und beantragen,
|
|
dass Microsoft seine Arbeit an MS-OOXML in ISO/IEC 26300:2006 (Open
|
|
Document Format) einbringt.
|
|
</p>
|
|
|
|
<p>
|
|
Dies ist eine Zusammenfassung. Ausführlichere Informationen
|
|
finden Sie online.
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<a
|
|
href="http://www.grokdoc.net/index.php/EOOXML_objections">http://www.grokdoc.net/index.php/EOOXML_objections</a>
|
|
</li>
|
|
<li>
|
|
<a href="http://www.xmlopen.org/ooxml-wiki/index.php/DIS_29500_Comments">http://www.xmlopen.org/ooxml-wiki/index.php/DIS_29500_Comments</a>
|
|
</li>
|
|
<li>
|
|
<a href="http://www.noooxml.org/arguments">http://www.noooxml.org/arguments</a>
|
|
</li>
|
|
</ul>
|
|
|
|
<ol>
|
|
<li>
|
|
<h3>Unabhängigkeit?</h3>
|
|
|
|
<p>
|
|
Ein Standard sollte niemals von einem bestimmten Betriebssystem,
|
|
einer speziellen Umgebung oder Software abhängig sein.
|
|
Anwendungs- und Implementierungs-Unabhängigkeit gehören zu den
|
|
wichtigsten Eigenschaften eines Standards.
|
|
</p>
|
|
|
|
<blockquote>
|
|
<strong>
|
|
Ist die MS-OOXML-Spezifikation frei von jeglichen Verweisen auf
|
|
einzelne Produkte eines Herstellers und deren spezifisches
|
|
Verhalten?
|
|
</strong>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<h3>Unterstützung bereits existierender Offener Standards?</h3>
|
|
|
|
<p>
|
|
Wann immer anwendbar und möglich, sollten Standards auf bereits
|
|
erzielten Erfolgen der Standardisierung aufbauen und die Abhängigkeit
|
|
von proprietären, herstellergebundenen Technologien vermeiden.
|
|
</p>
|
|
|
|
<p>
|
|
MS-OOXML vernachlässigt verschiedene, vom W3C empfohlene Standards
|
|
wie MathML und SVG, und benutzt stattdessen eigene,
|
|
herstellerspezifische Formate. Dadurch werden alle anderen
|
|
Hersteller, wenn sie MS-OOXML vollständig implementieren wollen,
|
|
gezwungen, sich in die proprietäre Infrastruktur einzuordnen, die
|
|
durch Microsoft in den vergangenen 20 Jahren aufgebaut wurde.
|
|
Es erscheint fraglich, ob ein Dritter diese Spezifikation
|
|
jemals in derselben Qualität wie Microsoft implementieren können
|
|
wird.
|
|
</p>
|
|
|
|
<blockquote>
|
|
<strong>
|
|
Was nützt es, wenn auf diesem Gebiet ein herstellergebundenes
|
|
Format auf Kosten der Standardisierung akzeptiert wird? Wo bekommen
|
|
andere Hersteller wettbewerbsfähige, kompatible und vollständige
|
|
Implementierungen dieser Formate für alle Plattformen, um untragbar
|
|
hohe Kosten zu vermeiden?
|
|
</strong>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<h3>Abwärtskompatibilität für jeden Hersteller?</h3>
|
|
|
|
<p>
|
|
Einer der angeblich größten Vorteile von MS-OOXML ist seine
|
|
Fähigkeit, Abwärtskompatibilität erlauben zu können, wie sie auch in
|
|
der <a
|
|
href="http://www.ecma-international.org/news/PressReleases/PR_TC45_Dec2006.htm">
|
|
Pressemitteilung der Ecma international</a> genannt wird.
|
|
</p>
|
|
|
|
<p>
|
|
Es ist für einen Standard unverzichtbar, dass er von jedem Hersteller
|
|
umgesetzt werden kann, ohne dass dieser auf die Kooperationsbereitschaft
|
|
anderer Firmen angewiesen ist, auf verborgene zusätzliche
|
|
Informationen zugreifen, zusätzliche juristische Abkommen schließen,
|
|
oder Zahlungen leisten muss. Ebenso muss ein Standard gewährleisten,
|
|
dass alle Hersteller ihn, ohne mit Wettbewerbern kooperieren zu
|
|
müssen, in der gleichen Qualität und im selben Umfang verwenden
|
|
können, um die notwendige Interoperabilität zu erreichen.
|
|
</p>
|
|
|
|
<blockquote>
|
|
<strong>
|
|
Kann ein Hersteller, unabhängig von seinem Geschäftsmodell, ohne
|
|
Zugriff auf zusätzliche Informationen und ohne die
|
|
Kooperationsbereitschaft Microsofts die Abwärtskompatibilität
|
|
seiner Produkte und die Umwandlung der eigenen Dokumentenformate in
|
|
das MS-OOXML-Format in derselben Qualität, wie sie von Microsoft
|
|
erreicht wird, erreichen?
|
|
</strong>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<h3>Proprietäre Erweiterungen?</h3>
|
|
|
|
<p>
|
|
Die Verwendung proprietärer, anwendungsspezifischer Erweiterungen ist
|
|
eine von Microsoft angewandte Maßnahme, um ihre Vormachtstellung im
|
|
Bereich der Desktopanwendungen zu missbrauchen und weiter auszubauen.
|
|
Wegen dieses Verhaltens sah die Europäische Kommission sich im Jahre
|
|
2004 veranlasst, eine Entscheidung gegen Microsoft zu fällen und den
|
|
Konzern aufzufordern, Informationen zu veröffentlichen, die die
|
|
Interoperabilität der Software anderer Hersteller mit der Software
|
|
des Konzerns ermöglicht. Microsoft weigert sich bis zum heutigen
|
|
Tage, dieser Aufforderung Genüge zu tun.
|
|
</p>
|
|
|
|
<p>
|
|
Aus diesem Grunde ist allgemein anerkannt, dass Offene Standards
|
|
niemals proprietäre Erweiterungen zulassen sollten und dass
|
|
wettbewerbsverzerrenden Verhaltensweisen, wie die oben genannten,
|
|
durch Offene Standards nicht unterstützt werden sollten.
|
|
</p>
|
|
|
|
<blockquote>
|
|
<strong>
|
|
Erlaubt MS-OOXML proprietäre Erweiterungen? Ist Microsofts
|
|
MS-OOXML-Implementierung vertrauenswürdig, ist sie z.B. frei von
|
|
undokumentierten Zusätzen? Existieren Maßnahmen, um dergestalten
|
|
Missbrauch zu vermeiden?
|
|
</strong>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<h3>Doppelte Standards?</h3>
|
|
|
|
<p>
|
|
Das Ziel aller Standardisierungsbemühungen ist die Einigung auf
|
|
einen einzigen Standard, weil mehrere unterschiedliche Standards
|
|
Wettbewerbsnachteile mit sich bringen. Die hier durch Microsoft
|
|
vorangetriebene Zersplitterung des Standards ist eine strategische
|
|
Maßnahme mit dem Ziel, die Kontrolle über bestimmte Bereiche des
|
|
Marktes zu erlangen, wie mehrere Beispiele aus der Vergangenheit
|
|
deutlich zeigen.
|
|
</p>
|
|
|
|
<p>
|
|
Es existiert bereits ein anerkannter Offener Standard für
|
|
Officedokumente, namentlich das Open Document Format (ODF) (ISO/IEC
|
|
26300:2006). Sowohl MS-OOXML als auch ODF liegt dieselbe
|
|
XML-Technologie zugrunde, wodurch beide Spezifikationen über
|
|
dieselben theoretischen Möglichkeiten verfügen. Microsoft ist
|
|
Mitglied der OASIS-Gruppe, jener Organisation, durch die der
|
|
ODF-Standard entwickelt wurde und gepflegt wird. Microsoft war über
|
|
den Prozess informiert und eingeladen, daran zu partizipieren.
|
|
</p>
|
|
|
|
<blockquote>
|
|
<strong>
|
|
Warum wies und weist Microsoft das Angebot bis heute zurück, an dem
|
|
bereits existierenden Standard mitzuwirken? Warum haben sie ihre
|
|
technischen Lösungen OASIS nicht zur Aufnahme in ODF vorgelegt?
|
|
</strong>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<h3>Juristisch sicher?</h3>
|
|
|
|
<p>
|
|
Für einen Standard ist es wichtig, dass alle Wettbewerber die
|
|
Möglichkeit haben, einen Standard ohne die Gefahr juristischer
|
|
Verfolgung implementieren zu können. Diese Zusicherung muss klar,
|
|
nachvollziehbar, verlässlich und weit genug gefasst sein, um alle für
|
|
die Interoperabilität notwendigen Prozesse abzusichern um einen
|
|
echten Wettbewerb zu ermöglichen.
|
|
</p>
|
|
|
|
<p>
|
|
MS-OOXML kommt, statt mit den typischen Patentrechtsbestimmungen, mit
|
|
einem unüblich komplexen und sehr eng gefassten "Vertrag, niemanden
|
|
zu verklagen" daher. Aufgrund seiner Komplexität ist unklar, wie
|
|
weit der Schutz vor Klagen tatsächlich gewährt wird.
|
|
</p>
|
|
|
|
<p>
|
|
Eine oberflächliche Überprüfung dieser Zusicherung ergab, dass nicht
|
|
alle optionalen Features und proprietären Formate, die für eine
|
|
vollständige Implementierung von MS-OOXML verwendet werden müssen,
|
|
durch diese Zusicherung abgedeckt werden. Dadurch ist die
|
|
Rechtssicherheit der Wettbewerber bei der Implementierung des
|
|
MS-OOXML-Formats gefährdet und hinsichtlich der Kernkomponenten
|
|
mindestens fraglich.
|
|
</p>
|
|
|
|
<blockquote>
|
|
<strong>
|
|
Hat Ihr nationales Standardisierungsgremium eigene, unabhängige
|
|
Untersuchungen über die juristische Natur des "Vertrages, niemanden
|
|
zu verklagen" vorgenommen, aus denen hervorgeht, ob tatsächlich das
|
|
gesamte Spektrum der möglichen MS-OOXML-Implementierungen abgedeckt
|
|
wird?
|
|
</strong>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>
|
|
Jede dieser Fragen sollte durch die nationalen Standardisierungsgremien,
|
|
auf Grundlage der Untersuchungsergebnisse unabhängiger Sachverständiger,
|
|
insbesondere frei von der Beeinflussung durch Microsoft oder ihre
|
|
Geschäftspartner, die in diesem Fall naturgemäß einem direkten
|
|
Gewissenskonflikt unterliegen, beantwortet werden.
|
|
</p>
|
|
|
|
<p>
|
|
Sollte auch nur eine der Fragen unzureichend beantwortet werden, muss das
|
|
Standardisierungsgremium in der ISO/IEC-Abstimmung mit "Nein" stimmen.
|
|
</p>
|
|
|
|
<h2>Verwandte Themen</h2>
|
|
|
|
<ul>
|
|
<li><a href="/documents/msooxml-interoperability.html">Interoperabilität leidet unter MS-OOXML</a></li>
|
|
<li><a href="/documents/msooxml-idiosyncrasies.html">DIS-29500 Normenentwurf noch vor seinem Einsatz veraltet?</a></li>
|
|
<li><a href="/documents/msooxml-converter-hoax.html">Der Konverter-Scherz</a></li>
|
|
<li><a href="/documents/msooxml-questions-for-ms.html">Fragen an Microsoft zu offenen Formaten</a></li>
|
|
</ul>
|
|
</body>
|
|
|
|
<timestamp>$Date$ $Author$</timestamp>
|
|
</html>
|
|
<!--
|
|
Local Variables: ***
|
|
mode: xml ***
|
|
End: ***
|
|
-->
|