Nee, kidde snapt het principe van standaarden wel. Deze dienen op dezelfde manier te worden opgesteld als de onderdelen van het UNIX besturings-systeem.
Elk onderdeel is gemaakt voor 1 taak, en doet deze taak goed. Dit geld voor UNIX CLI tools zoals ls, cd en cat. Maar ook voor standaarden, een standaard beschrijft 1 ding, geen 100.
Een standaard van 100 pagina's is gemakkelijker te beoordelen en verbeteren dan een standaard van 1000 pagina's. Daarnaast kunnen kleine standaarden makkelijker functioneren als bouwstenen voor complexere standaarden. Net als kleine simpele applicaties fungeren als bouwstenen voor complexere systemen.
Wanneer je alles in 1 app probeert te bouwen krijg je bugs. Dit geld ook voor standaarden, dan krijg je afwijkende landcode-notaties, datum-notaties, incompatibiliteit met de gregoriaanse kalender en andere fouten.
En het belang van het oplossen van deze fouten wordt gemakkelijker onder stoelen of banken geschoven bij een grote standaard. Wanneer er 10 critische fouten zitten in hoofdstuk 5 van een standaard van 5000 pagina's kan dat mbv statistieken worden afgedaan als onbelangrijk. Wanneer deze 10 critische fouten zitten in een eigen standaard van 150 pagina's zal deze op veel meer weerstand kunnen rekenen.
Al met al... grote logge standaarden zijn onverantwoord en onhandig. Daarom is ODF beter dan OOXML: ODF definieert een deel van alles wat nodig is om een office-document weg te kunnen schrijven en vertrouwd voor de rest op andere standaarden, sommige bestaan al, en anderen moeten nog geschreven worden. Maar de scope van ODF is duidelijk en afgebakend. Voor functie-support moet je bij standaard X zijn, voor databases voor standaard Y. etc...
Je mag dan misschien niet alle gegevens hebben om een volledige office-implementatie te kunnen maken. Maar je weet wel welk deel er nog niet gestandariseerd is. Om ervoor te zorgen dat je zo min mogelijk werk nodig hebt als de ontbrekende standaarden klaar zijn kun je meewerken aan de ontwikkeling van de ontbrekende stukjes.
Ik hoop dat het geheel nu duidelijker is... kleine atomische standaarden zijn beter dan grote 'one size fits all' standaarden. Als je alles met een standaard af kon hadden we geen ISO nodig, toch?!
edit:
premature 'submit'...
[Reactie gewijzigd door psyBSD]
Je kunt echt geen Office applicatie implementeren met de ODF spec alleen en ook niet als daarin andere standaarden hergebruikt worden.
Bovendien heeft het hergebruik van webstandarden bedoeld voor statisch webpagina hele foute ontwerp gevolgen. Deze webstandaarden zijn bijvoorbeeld niet bedoeld voor het bijhouden revisies zoals in office files wel kan.
Maar de scope van ODF is duidelijk en afgebakend. Voor functie-support moet je bij standaard X zijn, voor databases voor standaard Y. etc...
Een echt niet juiste gedachte. ODF is een samenraapsel van verschillende webstandaarden die nooit bedoeld zijn voor gebruik in Office documenten samen gepakt in een volstrekt ondergespecificieerde document specificatie.
Een voorbeeldje.
In zowel ODF als OOXML kan je documentstukken beveiligen tegen mutaties met een encrypted password. In ODF staat daar basically dat er een encrypted wachtwoord gebruikt moet worden en niets meer terwijl in de OOXML spec staan alle toegestane encrpytie methodes benoemd en met indien nodig een aanvullende methode hoe deze encryptie moet worden toegepast. Hoe dat in de praktijk in ODF werkt kun je nergens vinden tenzij je OpenOffice ga bekijken en uit de OOXML spec kun je dit zo implementeren.
De ODF spec ziet misschien lekker gestructureerd uit maar is echt niet makkelijk implementeerbaar of optimaal. Er zijn zeker zaken waarin de ODF spec beter is dan OOXML maar er zijn ook veel zaken waarin de OOXML beter is dan ODF.
Ik wil niet dat een document-standaard mij gaat voorschrijven hoe ik een document moet versleutelen. Encryptie-methoden zijn tijdelijke maatregelen, deze worden met hoge regelmaat gekraakt, vallen binnen het bereik van brute-force methoden en zijn dus binnen no-time verouderd.
No-WAY dat ik geloof dat een stelletje office-geeks kunnen voorschrijven welke encryptie ik zou moeten kunnen gebruiken op mijn documenten.
Als er in het document melding wordt gedaan van de encryptie-methode, dan is dat voor mij genoeg.
Ik wil niet dat een document-standaard mij gaat voorschrijven hoe ik een document moet versleutelen
Het idee is dat de door jou encrypted documenten door iemand die het secret kent weer te openen zijn met de editor/viewer van de concurrent, of met een op basis van de standaard nieuw geimplementeerde editor/viewer. Dit moet ook nog mogelijk zijn in een verre toekomst als jouw software niet meer beschikbaar is als referentiemateriaal. Eén van de hoofddoelen van een open standaard voor documentopslag is om zeker te stellen dat de eigenaar van de documenten niet afhankelijk is van één vendor of softwarepakket voor het raadplegen en bewerken van zijn informatie, nu en in de toekomst.
Juist voor encrypted documenten is het essentieel dat de standaard die ze beschrijft volledig open is, omdat bij een goed geimplementeerde encryptie de tekst beslist niet human readable is buiten een editor/viewer om.
Overigens mag (sommigen zeggen: moet) de encryptiemethode zelf best openbaar zijn, als het correct geimplementeerd is maakt dat voor de veiligheid van de encryptie niet uit. Als een encryptiemethode "gekraakt" wordt, is het meestal niet het gepubliceerde
algorithme dat gekraakt wordt, maar heeft iemand een (snellere) methode gevonden om de clear text data te herleiden zonder de secrets te kennen, vaak is dat een manier om de secret key te berekenen uit de encrypted data.
[Reactie gewijzigd door berend_engelbrecht]
Berend_engelbrecht:
Je hebt helemaal gelijk, maar je hebt mij mss verkeerd begrepen. Wat ik bedoel is het volgende:
Wanneer een standaard definieerd welke encryptie je mag gebruiken en hoe je deze moet implementeren limiteer je de keuze. Met alle risico's die dat met zich meebrengt.
Encryptie-methoden dienen inderdaad openbaar te zijn, en we zien dat diverse encryptie-methoden door de jaren heen gekraakt zijn of niet meer bleken te voldoen door de komst van meer rekenkracht.
Dat er een veld aanwezig is dat aangeeft welke encryptie-methode gebruikt wordt, daar sta ik helemaal achter. Dat deze standaard oplegd welke keuze je hebt... niet. Het dient hiervoor te verwijzen naar een encryption-naming-scheme oid. Zodat ook nieuwe encryptie-methoden kunnen worden gebruikt zonder dat hier een 'standard-chenge' voor nodig is.
Daar heb je gelijk in, maar als ik hAl goed begrijp is er in ODF
geen specificatie beschikbaar die beschrijft welk algorithme er gebruikt wordt in een versleuteld OpenOffice document (een bron zou ik overigens wel op prijs stellen). Dit betekent dan hoogstwaarschijnlijk dat er ook geen gestandaardiseerde voorziening is om in het document aan te geven welk algorithme gebruikt is. Als dat inderdaad zo is moet een organisatie die documenten archiveert er voor kiezen om in het geheel geen encrypted documenten te accepteren, omdat dit het onmogelijk maakt om zonder kennis van de reference software een decryptor te bouwen (ze hebben "iets" gekozen en gebouwd en niet in de standaard gedocumenteerd wat dat dan wel is).
Het is overigens niet zo gek als een archief(wet) eist dat gearchiveerde documenten omwille van de toekomstige leesbaarheid niet encrypted mogen zijn. Dit is bijvoorbeeld een beperking die opgelegd wordt in de PDF/A standaard voor archiveerbare PDF-documenten. Dit stelt dan natuurlijk wel hogere eisen aan de fysieke beveiliging van gearchiveerde documenten die vertrouwelijke gegevens bevatten, maar dat is niet anders voor een klassiek papieren of microfilm-archief.
[Reactie gewijzigd door berend_engelbrecht]