IBM en Sun gaan odf-ontwikkeling stimuleren

IBM en Sun hebben gezamenlijk de Open Document Format Toolkit Union in het leven geroepen. Deze organisatie wil met behulp van het opensource-project ODF Toolkit de ontwikkeling van nieuwe toepassingen voor de odf-standaard stimuleren.

Ontwikkelaars moeten met de ODF Toolkit onder meer eenvoudig nieuwe applicaties kunnen bouwen voor onder meer het automatisch aanmaken van rapporten als gevolg van database-queries, het indexeren of scannen van documenten voor zoekdiensten, het converteren van documenten in andere bestandsformaten, en het importeren en renderen op mobiele apparaten.

Sun heeft alvast de aftrap gedaan met de donatie van een eenvoudige api voor het lezen, schrijven en manipuleren van odf-documenten. Zo wordt onder meer een ODF Validator-tool aangeboden waarmee odf-bestanden zijn te valideren. De ODF Toolkit moet uiteindelijk een breed scala aan odf-software opleveren en odf als dominant bestandsformaat voor documenten propageren.

Het project is een voortzetting van een eerder initiatief dat vorig jaar is gestart en waaraan dezelfde teamleden verbonden zijn. De website van dat ODF Toolkit-project was echter nog ondergebracht als subdomein bij de site van Openoffice. Het nieuwe initiatief lijkt volgens Jay Lyman, analist bij 451 Group, dan ook 'een poging te zijn om de ondersteuning voor odf los te koppelen van het Openoffice-kantoorpakket dat onder leiding staat van Sun'. Bij het grote publiek zijn de twee nog teveel synoniem, onder meer omdat Openoffice het eerste kantoorpakket was met odf-ondersteuning.

Tussen neus en lippen geven IBM en Sun nog een sneer aan de Iso-standaardisatieorganisatie door alleen Oasis te prijzen om zijn standaardisatiewerk voor odf.

De verwachting is dat IBM tevens op 5 november zal aankondigen dat de ontwikkeling van toekomstige versies van Lotus Symphony zal plaatsvinden met odf 1.2 en Openoffice 3.0 als basis. IBM's gratis Symphony-kantoorsoftware gebruikte al Openoffice als basis voor zijn broncode, maar dat betrof een vorige versie.

Reacties (9)

[Verwijderd]

Compliment aan OASIS is tevens een beetje zelfbevlekking:

"Developing an XML-based file format specification for office applications

Michael Brauer, [e-mail], Chair
Robert Weir, [e-mail], Chair
Mary McRae, [e-mail], OASIS Staff Contact"
http://www.oasis-open.org...home.php?wg_abbrev=office

Maar evenzeer heeft de ISO het grootste deel van haar geloofwaardigheid recentelijk verloren.

[Little Penguin]

Uiteindelijk is het ISO niet echt betrokken geweest bij het tot stand komen van de OpenDocument- en ooxml-formaten. Dus in hoeverre het ISO dan expliciet genoemd moet worden.

Het leeuwendeel van de stadaardisatie van OpenDocument is gewoon door OASIS gedaan, waarbij de goedkeuring door het ISO slechts een soort van formaliteit was - in hoeverre men ook nog echt naar de inhoud van OpenDocument gekeken heeft weet ik niet, ik heb geen enkel bericht gehoord (de afgelopen 5 jaar) over onregelmatigheden/bijzonderheden in de landelijke standardisatie-instituten inzake ODF. (Niet dat dat gelijk zegt dat er bij ODF geen onregelmatigheden waren bij het tot een ISO standaard verheffen van de standaard - ik heb ze alleen nooit gehoord )

Bij OOXML is het leeuwendeel van de standaardisatie door Microsoft en het ECMA uitgevoerd en is, na een hoeveelheid gehakketak, de procedure om tot een ISO-standaard uiteindelijk ook een formaliteit gebleken - er is wel commentaar verwerkt, maar niet alle commentaar. Om nog maar te zwijgen over controverse in Nederland, Noorwegen en andere landen....

Overigens is het wel belangrijk voor de XML-based standaarden dat er goede en gemakkelijk toegankelijke ontwikkeltools komen. Op die manier kunnen bestaande programmeurs, met weinig/geen kennis van XML, toch OpenDocument documenten maken.

Als blijkt dat MS-Office in goed staat is om OpenDocument te lezen en de tools om OpenDocument aan te maken zijn zeer goed toegankelijk dan is dat een pluspunt voor OpenDocument. Dat dit formaat dan ook nog eens door de open source KOffice en OpenOffice.org gelezen kan worden is dan een extra bonus...

[Fireshade]

Uiteindelijk is het ISO niet echt betrokken geweest bij het tot stand komen van de OpenDocument- en ooxml-formaten. Dus in hoeverre het ISO dan expliciet genoemd moet worden.

Dat bedoelt snirpsnirp ook niet denk ik. Volgens mij is de ISO zelf nooit betrokken geweest bij de ontwikkeling sic van een standaard. De ISO is er alleen om standaardvoorstellen te beoordelen en te ratificeren.
Die standaarden worden ontwikkeld en voorgesteld door "externe" partijen (die natuurlijk wel deel kunnen nemen aan het ISO-ratificatieproces), in dit geval SUN (ODF) en Microsoft (OOXML).

De ISO heeft een deel van z'n geloofwaardigheid verloren door "chaotische", politieke en soms onbegrijpelijke beslissingen in het ratificatieproces rondom OOXML.

[Verwijderd]

Ik verwachtte dat het puur Java zou zijn, maar het is ook voor .NET, dat is mooi zeg. Microsoft is met Office en Visual Studio natuurlijk al een heel eind, maar het wordt tijd voor concurrentie. Als ze slim zijn bij IBM, maken ze ook tools om Office API calls te vertalen naar die voor ODF (of via een wrapper ofzo).

[Verwijderd]

Dude, dit gaat niet om API calls in een office applicatie, dit gaat om het kunnen werken met documenten in je eigen code zonder office applicatie. Er is helemaal geen API call voor ODF in de Office API. Zodra een document geopend is in memory van een Office app bestaat het hele concept Open XML / ODF / HTML / WhatEva niet meer, deze worden alleen gebruikt voor disk representatie van een document, niets meer.

[Verwijderd]

Aan de ene kant hoop ik dat er naast ODF en OOXML nog een derde formaat komt. Aan de andere kant is verdere versnippering natuurlijk in niemands belang. Toch zijn er technisch gezien goede redenen voor, want beide formaten hangen nauw samen met de office pakketten waaruit ze afkomstig zijn en dit uit zich dan ook in de gemaakte ontwerpkeuzes.

Persoonlijk zie ik ODF en OOXML dan ook geen van beide als het ultieme formaat. Het gaat me dan met name om het formaat voor de tekstverwerker.

Word en de tekstverwerker van StarOffice/OpenOffice zijn allebei objectgeoriënteerd (verwant aan, maar niet helemaal hetzelfde als, het gelijknamige programmeerconcept) en hun bestandsformaten zijn dat ook. WordPerfect werkt echter streamgeoriënteerd en dat blijf ik persoonlijk toch de betere insteek vinden. Het is jammer dat WP niet meer zo mainstream is als vroeger want ik kon er (letterlijk ) mee lezen en schrijven. De feature die ik het meest mis zal voor WP-adepten niet als een verassing komen en heeft ook alles te maken met het bestandsformaat. Uiteraard doel ik hier op het welbekende reveal codes, oftewel het onderwaterscherm.

[Supremo]

Volgens mij heb ik ergens een artikel gelezen dat streamgeorienteerd vaak ingegeven werd door performance en niet vanwege een "nette" standaard.

Maar als je zo graag low-level wilt werken, dan hernoem je je ODF file toch gewoon naar ZIP en dan kun je gewoon alles bijwerken.

Maar ik zie niet in wat reveal codes met het formaat heeft te maken. Naar mijn idee werkt zoiets onafhankelijk van het formaat.

[Verwijderd]

Het argument tegen reveal codes in Word was altijd dat niet nodig/zinnig/bruikbaar was omdat Word objectgeoriënteerd is.

Dat verschil is ook een van de redenen dat WP zo slecht is in het importeren van Word-documenten.

En ik kan een ODF file wel handmatig editten (lekker praktisch trouwens), maar dan blijf ik zitten met de onhandige opbouw.

[Verwijderd]

Eindelijk gaan Sun / IBM een beetje bijschakelen. Was het niet Steve Balmer die riep 'Developers Developers Developers!' Voor Open XML is er al een API in de Open XML SDK, en rechtstreeks in .NET (maar dan een low-level API). Werd eens tijd zou ik zo zeggen.