Jesper Lund Stocholm bloghoved

Document Freedom Day - kerneformater

Som du jo helt sikkert ved, er i dag hele verdens fødselsdag - eller i hvert fald den såkaldte "Document Freedom Day" - dagen hvor vi samlet i kor synger, at vi ikke vil lade os knægte, vi vil ikke lade os tryne, i samlet flok vil vi skabe en bedre verden.

Seriøst - formålet er ganske nobelt - nemlig at fremme anvendelsen af åbne dokumentformater - over en bred kam.

Da jeg i aftes sad og bladrede på Document Freedom day's hjemmeside, faldt jeg over en interessant artikel. Artiklen handler om "minimalistiske formater" og i al sin enkelthed er pointen, at traditionelle dokumentformater som ODF er for store og for komplekse at implementere for "små" leverandører.

I artiklen nævnes eksempelvis følgende

Manche Datenformate bauen dieses Problem sogar direkt ein: Es gibt von ihnen verschiedene Ausbaustufen. Wer hier feststellen möchte, ob Anwendungen kompatibel sind, der muss genau angeben, um welches Datenformat es sich handelt. Beispielsweise gibt es vom Open Document Format (ODF) mit 1.0, 1.1 und 1.2 schon drei Varianten. Vermutlich mit zunehmender Komplexität. Es gibt sicher viele Fälle, wo das Nutzen der Möglichkeiten von Version 1.0 völlig ausreichend wäre. Die Voreinstellung dürfte trotzdem das Speichern in der neuesten, von der Software unterstützten, Version sein.

Altså, med hver variant af ODF indføres ny kompleksitet og for langt de fleste ville det sandsynligvis være nok at bruge ODF 1.0

Og

Die Entwickler von einer Software, welche mit einem Datenformat umgehen soll, müssen die Beschreibung komplett durchdringen. Das umfasst den ganzen Text und dann alle Möglichkeiten, welche sich durch die Kombination der enthaltenden Elemente ergeben. Weniger lesen und verstehen zu müssen, bedeutet eine einfachere und sicherere Umsetzung in der Software. Das führt zu mehr Software, welche das Datenformat auf hohem Niveau spricht. Wettbewerb, Auswahl und damit mehr Nutzen für Anwender folgen nach.

Altså, en implementør af et format skal kende hele specificationen og alle varianter af alle muligheder. Et mindre format ville betyde mere stabilt- og mere sikkert software. En mindre specification vil betyde flere implementeringer af det og dermed mere konkurrence.

Forfatterens argumenter er jo ikke nye - her i Danmark fremføres de af og til og PHK har jo fra dag 1 sagt nogenlunde det forfatteren forsøger at argumentere for. Argumenterne er (lidt hårdt trukket op), at vi skal enten definere nogle basis elementer i eksempelvis ODF, der kan anses for "ODF Core" eller vi skal bruge flere forskellige formater afhængigt at den konkrete brug - dvs ODF den ene dag og HTML den anden.

Reality bites

Jeg er sådan set principielt set helt enig med forfatteren - de moderne dokumentformater er meget store og komplekse at implementere. Men jeg er tvivlende overfor det realistiske i målene fremadrettet og jeg synes hans præmis er for snæver til at få realistisk anvendende og "penetration". Han fokuserer nemlig udelukkende på ét scenarie - nemlig "afsendelse".

Core document formats

Idéen om ”Core formats” er god – og diskussionen om det springer frem sådan af og til. For ODFs vedkommende har man længe småsnakket om en ”ODF Core” profil, der skulle indeholde en slags basal funktionalitet i ODF og jeg har selv gået og grublet over, om vi ikke kunne gøre noget tilsvarende med OOXML.

Problemet opstår, når idéen rammer virkeligheden.

For det første har vi allerede i dag muligheden for at bruge disse ”Core formats”. For alle (dokument)standarder gælder det, at der ikke er noget krav om at implementere hele specifikationen – man kan reelt udvælge præcist de dele af fx ODF, som man ønsker at anvende. Vi har i CIBER jo efterhånden været involverede i dokumentformater i nogle år og vi har implementeret anvendelse af dem masser af gange for vores kunde. Men vi har aldrig implementeret en fuld kontorpakke. Vores kode har dannet tusindvis af dokumenter, men vi har aldrig implementeret en specifikation fra A – Z. Så vi har allerede muligheden for disse nedbarberede formater – det er blot at tage dem i anvendelse.

For det andet er det super nemt at heppe på disse ”Core formats”, når man snakker om ”afsendelse”. Men hvad sker der, når man pludseligt skal modtage noget? Det økosystem man dermed skal understøtte består jo alt overvejende af fulde kontorpakker, der løbende opdateres med ny funktionalitet. For OpenOffice.orgs vedkommende var processen fra ODF 1.1 til ODF 1.2 jo en periode på tre år, hvor funktionaliteten løbende blev udvidet med de halvårlige frigivelser af nye versioner af kontorpakken. For Microsoft Offices vedkommende tilføjes der ikke ny funktionalitet i samme løbende modus – her arbejder man mere med en ”big-bang frigivelse” af en masse ny funktionalitet – problemet med interoperabilitet er dog det samme. Her nytter det ikke noget at fokusere på Core formats – her er man død og pine nødt til at se på funktionalitetsrummet af hele det økosystem, som man ønsker at modtage dokumenter fra.

Andre formater

HTML nævnes specifikt som en mulighed i artiklen, og det er også noget, der af og til foreslås i debatterne herinde. Jeg tror dog desværre ikke, at den realistisk har anvendelsespotentiale. Problemet opstår igen i det økosystem af den skal finde anvendelse i. Her er det ikke et økosystem af kontorpakker – men derimod et økosystem af processer. Det er helt fint muligt at se på det isoleret pr. ”menneske”, og her giver det fint mening at skifte format afhængigt af den konkrete skrivesituation. Men hvis sådan en tilgang om formatskift skal nå bred ”penetration”, så skal det virke i organisationer som virksomheder, myndigheder og styrelser.

Og her er virkeligheden en ganske anden. Vidensmedarbejderne her arbejder med kontorpakken som det primære arbejdsværktøj – dvs det er fx LibreOffice som de bruger til at skabe tekst, lave præsentationer og lege med regneark. De har ét værktøj som de bruger til det hele – og det er vel sådan set også det de markedsføres som – nemlig præmissen om, at hvis man bruger kontorpakke X, så har man ikke behov for andre programmer på computeren. Jeg tror simpelthen ikke på, at det vil være realistisk muligt at "optræne" folk til at vurdere fra dokument til dokument i hvilket format det skal rundsendes. Isoleret set er det en sympatisk tanke - jeg tror bare ikke rigtigt på, at den vil finde anvendelse. Vi har efterhånden fået manifesteret i myndigheder og styrelser, at for en givet proces, så skal der anvendes et givet dokumentformat. Altså, for "publicér dokument på web"-processen skal anvendes PDF og for "rundsend redigerbart dokument"-processen skal anvendes et åbent dokumentformat som ODF eller OOXML. Men jeg tror ikke på, at vi kan få succes med at lave en vurdering af anvendelse af flere formater i en givet proces.

Men hvad gør vi så?

Tja - svaret blæser lidt i vinden. På godt og ondt er processer og dokumenter i dag bundet til de fulde, enorme kontorpakker som OpenOffice.org eller Microsoft Office, og jeg ser ikke dette blive ændret i de nærmeste år.

Men kom gerne med dit bud på, hvordan vi opnår bedre interoperabilitet og konkurrence - og gerne forslag, der kan implementeres i virkeligheden.

Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Peter Lind

Core ideen er vel meget god, så længe man laver mulighed for nemme plugins af andre små formater. Dvs. at du eksempelvis kan have et container-format med et minimalt format til tekst. Vil du så have indlejret diverse billeder eller tabeller eller what not, så skal vi ikke udvide formatet med nye ting - ej heller skal vi finde på smarte nye og mere komplekse formater, eller lave en mere omfattende version 1.2 udgave af formatet. I stedet gør man brug af andre, eksisterende formater, der kan give lige netop den begrænsede funktionalitet - disse indlejres så bare i dokumentet.

Jeg kunne forestille mig det ville give mere kaos til at starte med - men på længere sigt vil det gøre det ufattelig meget nemmere at starte op som leverandør af office-produkter, tror jeg. Derudover vil det også være ekstremt meget nemmere at tilføje nye dele til dokument-formater - i kraft af at man ikke ændrer selve formatet, man indlejrer blot ny funktionalitet i selve dokumentet.

På den vis er der også 100% backwards compatibility: ældre office-software vil altid kunne læse et dokument, men vil bare ikke kunne rendere dele af det hvis der mangler plugins. Dette vil så uden problemer kunne vises til brugeren - der så kan lede efter plugins til sin office-software.

  • 0
  • 0
#2 Torben Mogensen Blogger

Et problem med at definere en delmængde af et stort og komplekst format som et core-format er, at et dokument meget nemt bliver forurenet af ikke-core features. Hvis en bruger f.eks. læser et core-dokument ind i sin forkromede officepakke og retter en lille ting, kan man risikere, at officepakken gemmer det rettede dokument i et format, der bruger de ekstra features. Så enhver officepakke bør laves, så den advarer, når man går udenfor core-formatet og tillader, at man gemmer ethvert dokument i core-formatet mod at miste detaljer i formatteringen.

Så jeg vil foretrække, at man laver et basisformat, der er uafhængigt af de komplekse formater, og lader officepakker m.m. konvertere ved hent og gem. Der kan stilles det krav, at et dokument i basisformatet, der konverteres frem og tilbage uden at være redigeret, skal være uændret (modulo detaljer, der ikke har betydning for det viste indhold, f.eks. kommentarer, datostempler, og whitespace, der ignoreres af basisformatet).

HTML kunne godt fungere som et sådant basisformat, men selv HTML er måske blevet for kompliceret til formålet. Desuden mangler HTML grafiske elementer (uden at man skal ud i Javascript), som kunne være rare at have selv i et basisformat (f.eks. hvis basisformatet skal understøtte Powerpoint-lignende præsentationer). Simpel formelregning (til regneark o.lign.) kunne også være interessant.

  • 0
  • 0
#3 Peter Stricker

Kunne man ikke bare anvende OOXML strict, som vistnok specificerer, at man kun må anvende elementer fra Part1, 2 og 3 men ikke fra part 4.

Så kunne man også specificere, at en kontorpakke kun måtte påstå at overholde hele OOXML, hvis den både kan lave dokumenter, der overholder OOXML transitional og OOXML strict. Altså både dokumenter, hvor der er frit valg på alle fire hylder, og andre dokumenter, hvor det garanteres, at der ikke er medtaget elementer fra part 4.

Og hvis en kontorpakke der overholder hele OOXML modtager et dokument i formatet OOXML strict, så skal kontorpakken garantere, at den ikke, uden at advare brugeren, introducerer elementer fra part 4, da dette ville reducere dokumentet til OOXML transitional.

Man kunne endda indføre et tag der sammen med det tag (som jeg ikke kan huske), der definerer om dokumentet er strict eller transitional, også specificerer om dokumentet nedgraderes til transitional.

  • 0
  • 0
#4 Jesper Lund Stocholm Blogger

Core ideen er vel meget god, så længe man laver mulighed for nemme plugins af andre små formater. Dvs. at du eksempelvis kan have et container-format med et minimalt format til tekst. Vil du så have indlejret diverse billeder eller tabeller eller what not, så skal vi ikke udvide formatet med nye ting - ej heller skal vi finde på smarte nye og mere komplekse formater, eller lave en mere omfattende version 1.2 udgave af formatet. I stedet gør man brug af andre, eksisterende formater, der kan give lige netop den begrænsede funktionalitet - disse indlejres så bare i dokumentet.

Men sådan virker eksempelvis OOXML allerede den dag i dag. Den plug-in arkitektur du efterlyser gennemsyrer OOXML i dag - det er bare at gøre brug af den. Men uanset om man vælger at udvide et dokumentformat med ny funktionalitet eller indlejrer funktionalitet fra andre formater, så vil du altid stå i den situation, at en basal tekstbehandler måske ikke vil kunne forstå en tabel indlejret i LaTeX-format og dermed miste information.

For hvem skal bestemme, hvilken funktionalitet en "dokumentdanner" putter i sit dokument ... og hvem skal bestemme, om en bid information i et dokument er "vigtigt" eller ej?

  • 0
  • 0
#5 Jesper Lund Stocholm Blogger

Så enhver officepakke bør laves, så den advarer, når man går udenfor core-formatet og tillader, at man gemmer ethvert dokument i core-formatet mod at miste detaljer i formatteringen.

Det er jo faktisk den måde kontorpakker som OpenOffice.org, Apple iWork og Microsoft Office virker den dag i dag, hvor de anser deres eget "native" format som "Core" og advarer ved persistering i et andet format end "deres eget".

  • 0
  • 0
#6 Jesper Lund Stocholm Blogger

Så kunne man også specificere, at en kontorpakke kun måtte påstå at overholde hele OOXML, hvis den både kan lave dokumenter, der overholder OOXML transitional og OOXML strict. Altså både dokumenter, hvor der er frit valg på alle fire hylder, og andre dokumenter, hvor det garanteres, at der ikke er medtaget elementer fra part 4.

Det lyder som om, at du har en formodning om, at denne "full conformance" profil skulle være noget som leverandørerne af kontorpakker ville efterstræbe.

Sandheden er blot, at ingen kontorpakker i dag implementerer den fulde specifikation af hverken ODF eller OOXML. Det gør de respektive leverandører i øvrigt ikke noget for at skjule - det er de meget åbne om. Da ekspertpanelet for dokumentformater spurgte leverandørerne af kontorpakker i Danmark om deres programmer "implementerede den fulde speecifikation" (dvs al funktionalitet i standarden), svarede de alle som én noget i retning af "vores implementering er fuld overensstemmelse med kravene i standarden".

Man kunne endda indføre et tag der sammen med det tag (som jeg ikke kan huske), der definerer om dokumentet er strict eller transitional

Der findes ikke sådan et element eller attribut i OOXML. Man kender forskel på et Strict dokument og et Transitional dokument ved at kigge på de respektive XML-filers namespaces. Disse er nemlig forskellige for Strict og Transitional.

  • 0
  • 0
#7 Peter Lind

Men sådan virker eksempelvis OOXML allerede den dag i dag. Den plug-in arkitektur du efterlyser gennemsyrer OOXML i dag - det er bare at gøre brug af den.

Nu har jeg ikke nærstuderet OOXML, men jeg har en anelse om formatet er relativt omfattende (jeg husker nogen brokke sig over den ekstensive dokumentation, og det var ikke fordi der var mange eksempler, der fyldte). Jeg har dermed svært ved at se det som Core. Til gengæld lyder det meget positivt at de har den tilgang til tingene (i.e. plugin-baseret) som du fremhæver :)

Men uanset om man vælger at udvide et dokumentformat med ny funktionalitet eller indlejrer funktionalitet fra andre formater, så vil du altid stå i den situation, at en basal tekstbehandler måske ikke vil kunne forstå en tabel indlejret i LaTeX-format og dermed miste information.

Det har intet med "at miste information" at gøre - der er intet, der går tabt. Til gengæld kan det blive meget nemmere for den enkelte bruger at sammenstykke sit eget tekst-behandlings-system: det eneste du behøver er en tekst-behandler, der kan håndtere core-formatet og som har en plugin-engine, der i opbygning spejler dokument-formatet. Så kan alle og enhver give sig til at lave plugins til systemet og du er ikke længere afhængig af folkene bag libreoffice eller microsoft office for at sikre at lige akkurat dit dokument vil kunne vises.

For hvem skal bestemme, hvilken funktionalitet en "dokumentdanner" putter i sit dokument ... og hvem skal bestemme, om en bid information i et dokument er "vigtigt" eller ej?

Hvis du med dokument-danneren mener personen, der skriver, så er det vel givet at det er personen selv. Det er så bare op til mig som læser om jeg mener at de indlejrede dele er vigtige nok til at jeg vil finde et plugin, der kan vise dem.

  • 0
  • 0
#8 Peter Stricker

Det er så bare op til mig som læser om jeg mener at de indlejrede dele er vigtige nok til at jeg vil finde et plugin, der kan vise dem.

Det er bare ikke sikkert, at det er godt nok. Hvis du modtager et dokument med en indlejret LaTeX tabel, som i JLS's ovenstående kommentar, så er det jo ikke sikkert, at du kan læse dokumentet. LaTeX er ikke en del af OOXML, og det er ikke sikkert, at du kan få lov til at installere en plugin, der kan vise indholdet af tabellen.

Forestil dig en situation, hvor du er gået på biblioteket for at læse en henvendelse fra det offentlige. Den situation er tit blevet anført som universalløsningen for det offentliges kommunikation med borgere, der ikke selv har en computer.

Hvis du derimod instruerer din kontorpakke i, kun at anvende elementer fra parts 1, 2 og 3, så kan du som producent af dokumenter være temmelig sikker på, at alle dine læsere kan læse hele dokumentet.

  • 0
  • 0
#9 Peter Lind

Det er bare ikke sikkert, at det er godt nok. Hvis du modtager et dokument med en indlejret LaTeX tabel, som i JLS's ovenstående kommentar, så er det jo ikke sikkert, at du kan læse dokumentet. LaTeX er ikke en del af OOXML, og det er ikke sikkert, at du kan få lov til at installere en plugin, der kan vise indholdet af tabellen.

Hvilket er en god grund til at forkaste den office-pakke, der ikke giver mig den mulighed.

Forestil dig en situation, hvor du er gået på biblioteket for at læse en henvendelse fra det offentlige. Den situation er tit blevet anført som universalløsningen for det offentliges kommunikation med borgere, der ikke selv har en computer.

Hvilket vel uden de helt store armbevægelser kan løses med trusted repositories? Således kan jeg i dag hente pakker fra linux package archives og være sikker på at indholdet matcher hvad det skal ved at sammenligne fingerprints. Er der noget i vejen for at de forskellige kontor-pakker kan hoste deres eget plugin-archive med trusted code, hvorfra du så ikke vil have problemer med at installere plugins selv på bibliotekers computere?

Igen vil det blot være en konkurrence-parameter: jo flere og jo bedre plugins en kontor-pakke har, jo mere interessant bliver den for alle brugere. Og alle udviklere af kontor-pakker kan være med da the playing field er udjævnet i kraft af at der ikke er nogen, der får lov til at specificere kæmpe dokument-formater som kun de selv kan implementere.

Hvis du derimod instruerer din kontorpakke i, kun at anvende elementer fra parts 1, 2 og 3, så kan du som producent af dokumenter være temmelig sikker på, at alle dine læsere kan læse hele dokumentet.

Givet at dine læsere har valgt en kontor-pakke, der understøtte parts 1, 2 og 3. Sidst jeg tjekkede var det eneste format, der blev vist korrekt mellem alle større kontor-pakker, .txt - så jeg giver ikke meget for "jeg holder mig bare til lige denne mindre del af ooxml/odf" da begge dele stadig er så omfattende at der ikke er enighed om hvordan et dokument skal vises.

  • 0
  • 0
Log ind eller Opret konto for at kommentere