Hvad mener vi med en "Åben Standard" ... er OOXML åben?

I dette indlæg vil jeg gerne se på intentionen i B103 om brugen af åbne standarder og om OOXML overhovet er relevant i den diskussion.

For et par år siden havde en stribe foreninger med rødder i open source verdenen en mange måneder lang diskussion i DKUUGs standardiseringsgruppe. Fomålet var at dæmme op for tvivlsomme forsøg på at sige "vi er iiih så åbne", når verden lærer os at åbenhed nemt kan gradbøjes - blandt andet af Microsoft...

Vi har beskrevet de tre regler som udgør definitionen af en åben standardhttp://www.aabenstandard.dk/

En åben standard opfylder efter denne definition følgende krav:
Punkt 1: Veldokumenteret med den fuldstændige specifikation offentligt tilgængelig.
Punkt 2: Frit implementerbar uden økonomiske, politiske eller juridiske begrænsninger på implementation og anvendelse.
Punkt 3: Standardiseret og vedligeholdt i et åbent forum (en såkaldt "standardiseringsorganisation") via en åben proces.

Da det nu berømte beslutningsforslag B103 blev besluttet af et enigt folketing 2. juni 2006 var det en fantastisk dag, og især fordi de kloge politikere havde anvendt netop www.aabenstandard.dk og ikke OIO's noget "slappere" definition af en åben standard - OIO har sidenhen adopteret www.aabenstandard.dk :-)

Jeg tror samtlige læsere af version2 nu har set at slaget omkring ISO standarden ODF og Microsofts OOXML kører for fuld damp.

Hvor står OOXML egentlig i forhold til de tre kriterier? OOXML skal have tre plusser for at komme i kridthuset.

Punkt 1: OOXML er endnu ikke veldokumenteret. Det er kendt - se f.eks. http://www.grokdoc.net/index.php/EOOXML_objections at der stadig er udokumenterede dele af standarden.
Et minus tildeles.

Punkt 2: Dette punkt er lidt uklart for mig mht. OOXML. For nok har jeg lov til at implementere OOXML, men Microsoft har relevante softwarepatenter, som gør at jeg bliver lidt bekymret. Microsoft har godt nok givet en patent frihed for de relevante patenter, men det er uklart hvordan de ikke-dokumenterede dele er omhandlet.
Et andet spørgmål er desuden om OOXML overhoved kan implementeres på andet end Windows, hvis man skal have 100% match.
Et lidt uklart resultat her - måske et plus - nok mere et minus.

Punkt 3: Standarden er lavet af Microsoft i ECMA efter en ramme, der var at "Produce a standard which is fully compatible with the Office Open XML Formats" - med andre ord; ECMA skulle lave en standard, som 100% skulle være kompatibel med Microsofts forslag på 6000 sider. ... Doh (citat Homer Simpson).
Og hvad gør Microsoft, hvis ISO vælger at rette i ECMAs standard 376?
Sorry to say ...Et minus tildeles.

Konklusion; Det er ikke tre plusser i karakterbogen...

Nu kommer mit store spørgsmål - hvorfor er Microsofts OOXML
relevant i diskussionen omkring udmøntningen af B103?

/pto

P.S. en ekstra lakmusprøve på en åben standard er om der er mere end en program-implementation, som understøtter standarden på flere platforme.
OOXML på Linux - anyone''?

Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Niels Elgaard Larsen

For det første har vi jo slet ikke softwarepatenter i DK. Men derfor er det jo alligevel problematisk hvis der er patenter på en standard i andre lande.

For det andet kan Microsoft og andre jo også have patenter, der kan forhindre ODF implementeringer. Eller andre end Microsoft kan have patenter der dækker både ODF og OOXML implementeringer. Det er faktisk værre, for Microsoft har i det mindste lovet ikke at bruge deres patenter til at forhindre OOXML implementeringer (*). Softwarepatenter er bare noget skidt.

==
Q: If a listed specification has been approved by a standards organization, what patent rights is Microsoft providing?

A: We are providing access to necessary claims consistent with the scope of our commitments in that organization.

og

==
Q: Does this OSP apply to all versions of the standard, including future revisions?

A: The Open Specification Promise applies to all existing versions of the specification(s) designated on the public list posted at http://www.microsoft.com/interop/osp/, unless otherwise noted with respect to a particular specification (see, for example, specific notes related to web services specifications).

Det er jo ikke sådan et helt krystalklart løfte.

Hvad sker der fx hvis ISO (eller ECMA, ha) vedtager et format, som MS er uenig i og ikke poster på http://www.microsoft.com/interop/osp/

Christian Nobel

Jeg vil anbefale at man går ind på følgende side:

http://www.iponz.govt.nz/pls/web/dbssiten.main

vælger patent search, indtaster følgende nummer under NZ number: 525484 og denæst laver submit query (øverst på siden!).

Som jeg læser det, så har MS i New Zealand fået tildelt patent på det at gemme et tekstbehandlingsdokument i et XML ark, hvilket ikke harmonerer specielt godt med snakken om at være åben.

Noget lignende gør sig gældende i Canada, men der er det endnu ikke godkendt:

http://patents1.ic.gc.ca/details?patent_number=2427122&language=EN

Mere læsning generelt om emnet:

http://xml.coverpages.org/ni2004-01-27-a.html

At politikerne så overhovedet kan overveje OOXML er mig en gåde, al den stund der endnu ikke et tale om en ISO standard (dette holdt op mod at der reelt eksisterer en standard).

Og som sidebemærkning, Rambøls beregninger der ender med at give et politikerorienteret resultat (180 millioner) er det rene gætteværk, der ligeså godt kunne have endt med det modsatte fortegn, eller for den sags skyld 137 lyserøde elefanter.

/Christian

PS en personlig bemærkning til Peter:
Det ville klæde dig og andre som var med i Balmers NDA møde at forklare hvad sagen gik på, da der er ved at brede sig en vis misto til jeres objektivitet!

Michael Rasmussen

Af rapporten fremgår det, at kravet om bagudkompatibilitet tillægges
væsentlig betydning, hvorfor ODF medfører meget store udgifter til
konvertering, der bunder i, at administrationen internt må opretholde
en to-strenget strategi - MS Office og et andet officeprodukt der
understøtter ODF. Denne dobbeltstrategi skyldes, at selv om et givet
andet produkt understøttede EOOXML, ville der ikke være garanti for, at
konverteringen kunne foregå 100% fejl/tabsfrit. At der ikke kan gives
100% garanti for fejl/tabsfri konvertering, skyldes den omstændighed,
at netop de elementer i EOOXML der omhandler konvertering af tidligere
MS Office formater ikke er specificeret i specifikationen, og ej heller
bliver det, da disse elementer er omfattet af Microsoft patenter, og
selvom specifikationen indeholder en pasus om ikke at påtvinge
patentrettigheder vedrørende specifikationen til konkurrerende
implementationer, gælder denne rettighedsafståelse ikke for elementer i
specifikationen, der alene er medtaget med det formål, at sikre
bagudkompatibilitet til tidligere dokumentformater i Microsofts
officepakker. Det vil derfor ikke være muligt for nogen anden
leverandør end Microsoft, at kunne tilbyde fejl/tabsfri konvertering af
den eksisterende dokumentbase, hvorfor et andet valg en EOOXML leveret
af Microsoft uværligt medfører ekstra omkostninger.

/Michael

Jens M Jensen

OOXML kommer aldrig til at opfylde pkt 2 af åben standard definitionen, fordi den netop ønsker at være bagud kompatible med proprietærer standarder. Den forsøger at opnå dette mål, ved at genbruge proprietærer teknologier, og dermed opstår modsigelsen, der vil forhindre, at OOXML kan betragtes som en åben standard,

Der omtales en lang række af disse teknologier, i den 6000 sider lange specifikation, uden at de er nærmere beskrevet.

Microsoft har udtrykt deres holdning omkring den frie tilgængelige af "enabling technologies"

Citat fra http://www.microsoft.com/interop/osp/default.mspx

Q: Why doesn’t the OSP apply to things that are merely referenced in the specification?

A: It is a common practice that technology licenses focus on the specifics of what is detailed in the specification(s) and exclude what are frequently called “enabling technologies.” If we included patent claims to the enabling technology, then as an extreme example, it could be argued that one needs computer and operating system patents to implement almost any information technology specification. No such broad patent licenses to referenced technologies are ever given for specific industry standards.

Jeg har fuld forståelse for, at Microsoft skal beskytte deres forretning, og derfor har behov for en sikring imod, at alle deres teknologier bliver frit tilgængelig.
Dette betyder efter min mening at man ikke kan anvende disse teknologier i en åbne standard, der skal være frit implementerbar

Fordi Microsoft insistere på, at anvende disse teknologier i specifikationen af OOXML, har de ikke leveret en åben standard, men en detaljeret specifikation af en proprietær standard.

Når standarden dermed ikke er frit implementerbar, kan man ikke forvente en bred udnyttelse af specifikationen på tværs af flere leverandører.

Når specifikationen ikke udnyttes af en bred vifte at leverandører, vil man ikke opnå den ønskede konkurrencemæssige fordel, som er et af de centrale argumenter for vedtagelsen af B-103.

Derfor er det efter min mening irrelevant at forsøge realisering af B-103 v.hj.a OOXML, som specifikationen fremtræder i dag.

Peter Juhl Christiansen

Det klogeste sagt i denne sag(citat fra en anden tråd):

"Man har politisk bestemt at der skal vælges 1 (én) standard til formålet - der er kun 1 iso standard.

Hvor svært er det? Hvor mange eksperter skal udtale sig om det?"

Jeg vil foreslå at Version2 (evt i aliance med andre medier) går offensivt ind i denne debat.

Lave en underskrifts indsamling, blandt "IT-eksperter" alias Versions2 læserer, tag oven stående citat (måske omformuleret) og få læserne til at skrive under med navn og stilling og send den til alle it-ordfører.

René Løhde

Hej Peter,

Lige et par hurtige svar herfra (og du mener
vel ”hvorfor er ECMA 376...”) :

  • Fordi det IT arkitektur mæssigt er et plus at få en åben repræsentation af gamle og nye tekstdokumenter
  • Fordi at ECMA 376 har stærke kvaliteter, som kan understøtte processor i den offentlige sektor, som f.eks ikke er muligt med ”.doc” dokumenter.
  • Fordi ECMA 376 er med til at flytte grænserne for det som traditionelt betragtes som et tekstdokument og der igennem innovere
  • ... og fordi ECMA 376 er en åben standard i henhold til de selvsamme links, som du har i din post

Kommentarer til dine punkter:

Pkt 1
Mange standarder har udokumenterede dele – eller som man siger i de kredse – det er overladt til applikationen(og dermed udvikleren) at fortolke denne del! ODF og W3C Xml Schema har også den slags udokumenterede dele, som er overladt til fortolkning.

Pkt 2
Du er inde på noget, som ligger min gode ven Jean meget på sinde. Jean har været med i arbejdsgruppen, som standardiserede OpenXML til ECMA 376. Hvis du finder noget eller nogen som helst forhindringer (patenter, jura etc.) der forhindre dig eller andre i at implementere så lad mig vide det, for så vil jeg tage det op med Jean. Meget af hans tid går med at få juristerne til at simplificere og fjerne eventuelle hindringer for implementering af OpenXML. I den forbindelse vil jeg gerne høre om du har de samme betænkeligheder mht. til de patenter f.eks Sun har på ODF? Hvis du mener at Sun gør et bedre arbejde end Microsoft mht at forklare og ”frigive” Suns rettigheder/patenter relateret til ODF – så mener jeg helt klart at Microsoft bør lære af det.

Pkt 3
ECMA 376 – ECMA – en standardiseringsorganisation - ECMA 376 tilhører ECMA. Standarden er udarbejdet i en komite med medlemmer fra f.eks Novell og Apple i en åben proces. Det er et eksakt match med punkt 3 i den definition af åbne standarder, som du henviser til. NB! Personligt er jeg tilhænger af ITST's definition af åbne standarder og det er specielt kravet om standardiseringsorganisation i pkt 3 jeg ikke bryder mig om.

Angående ændringer så kan jeg ikke spå, men jeg kan fortælle en historie fra Microsoft, som fandt sted sidst år. Da Microsoft gav OpenXML til ECMA var specifikationen på 2000 sider. I løbet af arbejdet med standarden voksede specifikationen til 6000 sider – alt sammen public info. I løbet af den tid udviklede Microsoft på Office 2007 og Microsoftmedarbejderne er naturligvis test på alle alpha’er og beta’er. I forbindelse med at OpenXML spec’en gik fra 2000 til 6000 sider var der ”breakable changes” i OpenXML, som betød at vi fra anden beta ikke længere kunne læse de ”gamle” OpenXML dokumenter. I den forbindelse valgte Microsoft IT at sætte en konverteringsservice op på vores intranet. Så tilbage til dit spørgsmål – Microsoft har prøvet at implementere ændringer til standarder og vil helt sikkert komme til at gøre det igen (FYI Den næste bliver nok OASIS WS-RX, der som standard ikke ligner den spec vi har implementeret i vores software stack)

Mange hilsner
René Løhde, Microsoft

Jesper Krogh

Hej Rene.

Der er en hel stribe problemstillinger og kritikpunkter her. Der er også andre steder på nettet hvor de fint er samlet sammen.

http://www.grokdoc.net/index.php/EOOXML_objections

Alle de smukke og rare ting du nævner øverst er jo dejligt at Microsoft har erfaret, men det er jo ikke egenskaber ved EOOXML men egenskaber ved blot at have et format der er til at forstå for enhver programmør og ikke et lukket leverandørejet format som det verden kom fra. Altså et stort skridt i den rigtige retning.

Men disse herligheder har vi jo haft med StarOffice/OpenOffice formaterne i et årti og det er disse erfaringer der idag er ISO-standardiseret i ODF. Og det var jo med armen vredet godt op i nakken at Microsoft overhovedet begyndte at tænke på at lukke op for de lukkede formater.

Jesper Krogh, SSLUG

Peter Toft

Kære René

Dejligt at se at du tager dig tid til at kommentere dette indlæg - og ret forventeligt :-)

Du skriver angående "Punkt 1" at det er ofte på den måde at applikationerne selv må fortolke. Tillad mig en analogi. Du kan sagtens læse dette og derfor kan vi kommunikere - men når nu skriver "pingu pingi pingus pingvinus pingvinia" så står du nok af og mister betydningen af min tekst[1]. Du kan ikke konvertere min tekst 100% til dit sprog-center i hjernen. På samme måde er det et stort problem hvis "dele af standarden" er op til dig selv at gætte hvad det pingvinsprog nu er for noget. Tilsvarende har jeg lidt svært ved at gætte de manglende elementer af Microsofts OOXML-standard - nu ECMA 376.
Derfor bliver det også særdeles interessant om ISO optager denne standard. Hvis de ikke gør lider I fra Microsoft et enormt tab - prestigemæssigt og I bliver sikkert nødt til at offentliggøre jeres ODF-support. Hvis ISO accepterer ECMA 376, så ryger ISOs anseelse i praksis langt ned bla. pga. de manglende dele af standarden.

Angående punkt 2 og SUN - klart enig om at hvis SUN (eller Microsoft) påviseligt har patenter, som blokerer for implementeringen af ODF, så er det også et reelt problem. Du er velkommen til at oplyse om dette skulle være et reelt problem eller FUD. Mht. Microsofts patent-"frit lejde", så påtalte bl.a. jeg og mange andre fra SSLUG og DKUUG at jeres patent-ordning i 2004 var håbløs - da den ikke gav mulighed for at være distributør af GPL-kode der implementerer jeres reference schemaer.

Ad Punkt 3. Vi som var med at til definere punkt 3 havde klart fokus på den stategi med at smide en kæmpe standard ud til offentligheden hvert 2-3 år som ingen kunne implementere på rimelig tid og derfor ville dem som definerede standarden kunne opretholde et reelt monopol alene ved at "force" større opdateringer jævnligt uden om andre spillere. Så jeg er meget stor tilhænger af punkt 3, og vil faktisk gerne have et punkt 4 som kræver multiple implementeringer på forskellige platforme - hvoraf en skal være på BSD eller GPL licencen før vi kalder det en åben standard.

Tak René - jeg ser ligesom andre frem til mere skriveri om emnet. Vi har klart ikke samme holdninger til emnet - men det er en anden sag :-)

[1] Er det ikke alle Linux-folk som lærer "pingvin-sprog"? - det kan læres i DKUUG eller SSLUG. Du er velkommen i vores sprog-skole :-)

Peter Toft

Kære Christian

Læs http://www.version2.dk/artikel/2290 som dækker mødets oplæg. Vi havde lavet en gentleman aftale om ikke at udtale os til pressen alene for at kunne tale frit fra leveren - at en ansat hos Microsoft kom til at tale over sig om dette til version2 er en anden sag suk

Jeg har rodet med Linux og Open Source fra før Open Source begrebet fandtes. Jeg har haft det privilegium at føre SSLUG fra 50 medlemmer til ca 5000 medlemmer. Jeg har været bannerfører på www.linuxbog.dk og senest næstformand for DKUUG. Jeg er ikke objektiv :-) Jeg kæmper for åbne standarder og fri software, hvilket du nok har gættet.

P.S. Jeg kan nu se at Kurt Westh Nielsen i http://www.computerworld.dk/art/39242 startede en "tanke om konspirationsteorier" som må stå for hans egen regning. Spændende hvor han kan få den tanke fra for realisme har den ikke :-)

Michael Rasmussen

Hej Rene,

Af følgende "Hvis du finder noget eller nogen som helst forhindringer (patenter, jura etc.) der forhindre dig eller andre i at implementere så lad mig vide det, for så vil jeg tage det op med Jean" kan jeg læse, at du efterspørger hindringer for andre ved at implementere EOOXML, så derfor kan du jo starte med at videregive mine betragtninger til Jean, som jeg har skrevet i indlægget: Åben for hvem?

I øvrigt synes jeg det er pudsigt, at du i mange sammenhænge efterlyser spørgsmål til hindringer i EOOXML, men når der stilles spørgsmål, undgår du enten helt at kommenterer dem, eller også afspiller du blot sidste bånd fra MS' presseafdeling! Hvornår for vi et fagligt svar på alle de rejste spørgsmål uden indblanding af politisk propaganda?

/Michael

René Løhde

Hej Jesper,

Et eksempel: Det jeg sætter størst pris på ved OpenXML og som ODF ikke har pt. er mulighed for ”egne” xml instanser indlejret i tekstdokumentet. (se eksempel her: http://blogs.msdn.com/renel/archive/2007/04/27/brugerdefineret-xml.aspx)

Jeg kan komme til at stå i en ”ODF only” situation i 2008 hvor jeg må fortælle IT arkitekterne i mit community at hvis de laver systemer til det offentlige kan de ikke længere bruge denne mulighed. Det er at give afkald på 10 års udvikling, som ellers kunne bruges meget fornuftigt inden for den digitale forvaltning.

NB! Hvis det er convergens vi ønsker - så bliver dette ikke sikret ved at udelukke en standard!

Peter,

Selv tak,

1) Jeg kender godt den Grokdoc side, som du og Jesper henviser til og de udokumenterede (eller delvist dokumenterede) attributter – f.eks ”autoSpaceLikeWord95”. Hvis du mener at dette udgør et væsentligt problem i OpenXML, så er det vel også et problem i ODF når det bliver overladt til udvikleren selv at fortolke attributter?...og ISO har vel ikke tabt anseelse ved at ratificere ODF? Brian Jones har lavet en sammenligning af hvordan disse formateringsattributter bliver brugt i de to specifikationer: http://blogs.msdn.com/brian_jones/archive/2007/02/20/beyond-the-basics.aspx

2) Jeg tror ikke at SUN forhindrer at andre bruger ODF – ligesom jeg heller ikke forventer at Microsoft stiller noget i vejen for at du kan bruge OpenXML.

Angående den ”uklarhed” du skrev om på dette område – tillad mig at hjælpe med at skabe klarhed – jeg tager udgangspunkt i den føromtalte autoSpaceLikeWord95.

I ECMA spec’en (del 4, side 1378 - pdf version) står der at jeg ikke bør implementere attributten - ” It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents”. Hvis jeg så alligevel har et stærkt behov for at implementere dette, så vil jeg finde ud af hvad denne attribut "gør". Jeg kan læse at denne attribut fortæller hvordan afstanden mellem ”East Asian” skrifttegn fortolkes. Jeg går ud fra at det f.eks kunne være japanske eller kinesiske skrifttegn (Dvs ikke noget, som er voldsomt aktuelt i en national B103 kontekst).
Bottomline: For at fjerne den uklarhed du omtaler, skal jeg altså undersøge om Microsoft har et patent eller nogle rettigheder, som forbyder andre at fortolke afstand eller ”luft” mellem disse østasiatiske skrifttegn.
Mener du virkelig at dette er et minus i karakterbogen?

3) Jeg kan godt forstå dine bekymringer på dette punkt. I den forbindelse ser jeg det som en vægtning mellem 1) faren for at den store virksomhed skulle dumpe en nye standard hver 2-3 år mod 2) den agilitet, som gerne skal være til stede for de små virksomheder. Jeg mener at det er vigtigst at tilgodese innovation blandt de små virksomheder og sikre at de ikke først skal igennem et overhead af standardisering før de har en chance for at få en kontrakt i det offentlige.

...og jeg tror muligvis at jeg er medlem i SSLUG – tjekker lige op på det. Så kommer du også til mit næste arrangement hos Microsoft? :-)

Hej Michael,
Jeg er helt sikkert fraværende nogen steder – det er en ret ophedet debat, både on – og offline. Denne diskussion og emnet er ikke en af min stillingsbeskrivelse, så jeg forsøger kun at deltage når jeg mener debatten er blevet for sidetung.

Anyway - hvis du og jeg skal blive meget konkrete på hvad jeg skal snakke med Jean om – er det så ....

[Action] -at undersøge om Microsoft kan forhindre andre leverandører i at lave en bestemt afstand mellem østasiatiske skriftegn? (Jvf pkt 2 ovenfor)

Eller hvis vi tager den næste fra Grocdoc – ”footnoteLayoutLikeWW8” (ECMA spec, 4 del, s. 1416, PDF version) – igen der er tale om et element i spec’en, som vi bliver anbefalet ikke at implementere dette: ”It is recommended that applications not intentionally replicate this behavior as it was deprecated...”.

[Action] -Skal jeg undersøge om Microsoft juridisk kan forhindre andre i at angive en placering for fodnoter i et tekstdokument, relativt til resten af teksten?

Jeg er ikke nogen patent-/rettighedsørn – jeg kan mærke juristerne griner når jeg forlader rummet! Men det forkommer mig underligt at Microsoft skal investere tid og ressourcer i at holde andre ude, ved hjælp af elementer som ECMA gruppen (altså herunder Apple og Novell) mener bør fjernes fra standarden.

-René

Jesper Krogh

Hej Rene.

Ret mig lige hvis jeg har misforstået din pointe.

Du skriver at MS-OOXML kan indlejre andre XML-stumper og dit favoriteksempel er at du on-the-fly kan gemme dit dokument i OIOXML's eFaktura-format?

Kan du komme med bare et eneste godt argument for at det stykke processeringskode/xml der skal til for at omforme et tekstdokument til en eFaktura bør være bundet til tekstdokumentformatet?

En opdatering er eFaktura-formatet vil derefter kræve at du konverterer alle dine tekst-dokumenter ellers vil funktionaliteten ikke virke.

Fortæl mig at jeg har misforstået din pointe, ellers håber jeg du kan finde på bedre eksempler.

Jesper

René Løhde

Hej Jesper,

Dette er et forsøg på at løse en bestemt problemstilling: Det er svært at skrive et stykke kode, som kan omforme et vilkårligt tekstdokument til en bestemt struktur (f.eks eFaktura).

Jeg har ikke set et succesfuldt scenarie hvor struktureret data bliver skabt i tekstdokumenter. Jeg vil rigtig gerne i dialog om en andre mulige tilgange til problemet.

Jeg kender til løsninger hvor man ”låser” en skabelon og håber på at brugerne kun bruger forudvalgte områder til indtastning af data – og at man så efterfølgende lader applikationer uddrage struktur på baggrund af formateringen i skabelonen.

Der er en del problemer i det scenarie...

1) I modsætning til mennesker har en applikation meget svært ved at finde semantisk struktur i en tekst, på baggrund af tekstens formatering

2) sammenkobling af præsentation til repræsentation er sjældent en god ting (det er vel også det man i webudvikling forsøger at komme væk fra)

3) selv hvis det skulle lykkedes at få uddannet og formanet over for brugerne at de skal udvise diciplin når de arbejder med skabeloner, så er det min erfaring at alle har deres personlige stil – alle!

Det er de problemer, som kan afhjælpes med denne funktionalitet.

Angående opdatering – ja, du har helt ret, som ved alt anden IT er der en versioneringsproblematik, som skal håndteres.

Jeg tror dog det vigtigste plus på dette, er friheden til at vælge den arkitektur (og de komponenter) du mener er fornuftig for dit system. Så hvis du laver systemer som er dokumentcentriske, er kollaboration på dokumenter, har content based routing, filtering med, det IBM kalder, XML firewalls og generel xml messaging, osv – så har du her en komponent, som passer ind og bringer merværdi.

-René

Eskild Nielsen

'Eller hvis vi tager den næste fra Grocdoc – ”footnoteLayoutLikeWW8” (ECMA spec, 4 del, s. 1416, PDF version) – igen der er tale om et element i spec’en, som vi bliver anbefalet ikke at implementere dette: ”It is recommended that applications not intentionally replicate this behavior as it was deprecated...”.'

Standarder forventes normalt at beskrive hvad og hvordan noget skal laves.

I forbindelse med vedligeholdelsen af standarder kan det forekomme, at der på et tidspunkt vil komme til at stå at en ud af flere mulige måder at implementere noget på ikke længere bør bruges i ny udvikling - eller et andet i den retning.

Men at førsteudgaven af en standard indeholder den slags dødvægt er stort set uhørt

/eskild

Død Profil

Hej Peter,

Jeg var lige inde og kigge på den
http://www.aabnestandarder.dk/ du henviser til.

Jeg synes den er lidt "pinlig" idet der ikke er nogen kommercielle virksomheder repræsenterede (muligvis indirekte gennem KLID olign). Kunne man ikke lave et kort skriv til en række virksomheder der har taget stilling, og få dem til at være aktivt med? IBM popper lige op som en kandidat?

Ser også at OEJLUG ikke er med, suk :-)

Mvh,
Søren

Leif Lodahl

René Løhde forsøger i sit indlæg herover at argumentere ved hjælp af at fremkomme med tekniske herligheder om OOXML. Det er bare ikke godt nok, René.

Diskussionen handler jo ikke om, hvilket format der er bedst, sådan teknisk set. Baggrunden er, at Folketinget HAR kridtet banen op: "Det skal være en åben standard", og det lever OOXML ikke op til.

Af samme årsag er PDF-formatet på forhånd diskvalificeret fordi Adobe i det mindste er ærlige omkring formatets lukkethed.

Hvis nogen er i tvivl, så prøv at kigge på denne rapport, som er udarbejdet for OIO: ”Research about OpenXML, ODF & PDF”, som er udarbejdet af Ovitas AS i Norge ( http://www.oio.dk/files/Research_OXML.ODF2.pdf )

Med venlig hilsen
Leif Lodahl

René Løhde

Hej Leif Lodahl,

Jeg forsøger ikke at sige hvilken af de to standard, der er teknisk overlegen (det tror jeg ikke er muligt) – jeg forsøger at illustrere at der er store forskelle på de to standarder. Det gør jeg fordi at debatten fejlagtigt er drejet derhen hvor det nu er et valg mellem en eller to nøjagtig ens standarder som dækker det samme forretningsområde, funktionalitet og designmål.

Angående graden af åbenhed – hvis du og Ovitas mener at standarder, som kommer fra ECMA ikke bør være standarder, så er det vel noget I bør tage op med ITST og ministeren. For nu vil jeg henlede din opmærksomhed på antallet af standarder som ECMA har leveret til ISO i forhold til ..... f.eks OASIS.

Jeg tror også at det bliver svært at opsætte kvalitetskrav og stramme definitionen på hvad der kvalificerer til at være en standardiseringsorganisation. En stram definition vil betyde at f.eks. OIOXML standarderne så ikke kan falde inden for rammerne af B103 – jvf. Min analyse her http://blogs.msdn.com/renel/archive/2007/03/19/mit-h-ringssvar.aspx ....og det ville jo være en mindre katastrofe for projekt digital forvaltning hvis det skulle ske.

-René

Log ind eller Opret konto for at kommentere