ISO's OOXML-afgørelse i tidsproblemer
I næste uge skal det afgøres, om Microsofts bud på et åbent dokumentformat skal gøres til ISO-standard, men allerede på forhånd er der spekulationer fremme om, at tidspres kan ødelægge processen.
Der er afsat fem dage til mødet, der officielt kaldes Ballot Resolution Meeting (BRM), og som endeligt skal bearbejde de ændringsforslag eller kommentarer, der kom ind i forbindelse med de nationale standardiseringskomiteers afstemninger, om OOXML skal gøres til ISO-standard.
Kan blive et ja
En afstemning, der blev afholdt i begyndelsen af september sidste år, og som i første omgang resulterede i et nej til standarden. 'Nej'et' var dog fulgt af kommentarer, der for lande som eksempelvis Danmark, i fald de imødekommes, vil ændre den danske indstilling til et 'ja'.
Oprindelig kom der 3522 indvendinger mod OOXML, og selv om dette antal er blevet reduceret til 1027, giver det stadig kun mødet, der afholdes i næste uge i Geneve, omkring to minutter til at behandle hvert punkt.
Tidspresset er allerede erkendt af lederen af det kommende møde Alex Brown, der på sin blog har regnet sig frem til, at afstemningerne bare med håndsoprækning alene vil tage over 34,1 timer af de 35 timer, der er afsat til møder over de fem dage.
Vi når det nok
Han har derfor lagt hovedet i blød for at finde alternativer til den gængse brug af ISO's afstemningsregler, så alle punkter kan behandles i overensstemmelse med reglerne, men uden at hvert punkt gøres til genstand for en individuel afstemning. Et af alternativerne kan være skriftlige afstemninger.
I Dansk Standard oplyser centerchef Pia Elleby Lange, at ifølge ISO's regler, så skal alle punkter behandles, men hun er dog også overbevist om, at det vil de blive.
»Vi har ikke set den endelige oversigt over, hvordan forløbet bliver, men jeg er fuld af fortrøstning til, at vi nok skal komme alle punkterne igennem,« siger hun til Version2.dk.
Mulighed for en om'er
Lykkes det ikke mødet i Geneve at nå frem til en afgørelse, er det dog ikke helt slut for OOXML. Pia Elleby Lange oplyser, at landene har 30 dage til at give ISO besked om, hvorvidt de fastholder deres oprindelige indstilling, eller de har ændringer.
»Ender det så derefter med, at der ikke kan skabes et flertal for OOXML, så bliver materialet sendt tilbage til ECMA, der så kan vurdere, om de vil gå videre med det eller ej,« siger hun.
På BRM-mødet i næste uge deltager fra Danmark folk fra Ciber, Microsoft, IBM og Dansk Standard.
Kommentarer (19)
Det har siden oktober været kendt at der var ca 3500 indvendinger imod OOXML som den foreligger.
Og det har også været kendt at 120 personer har 1 arbejdsuge til at gennemgå dette materiale i.
Og at ECMA har forebredt svar på en del af dem - dog i mange tilfælde uden substantielle ændringer.
Vi må derfor forvente at ved udgangen af næste uge, så er der ikke sket meget andet and at 120 personer har en ny buke rejsebilag at bogføre.
/esni
-
0 -
0
Eskild,
Vi må derfor forvente at ved udgangen af næste uge, så er der ikke sket meget andet and at 120 personer har en ny buke rejsebilag at bogføre.
Og frequent-flyer-miles!
:o)
Vi finder i øvrigt også ud af, om jeg skal give PHK øl eller ej.
-
0
-
0
At se hvordan specielt Open Source folkene slår sig i tøjet for at Microsoft ikke skal komme med for mage ting som er Åbne og bliver til stander.
Det er ret så åbenlyst et forsøg på at "holde" Microsoft til at være en "prygle knap" og bruge Microsoft som argumentation for at skifte til flere Open Source produkter. Skulle Microsoft få deres forehavende med OOXML igennem så er det jo et klart slag mod Open Source produkter som netop har slået sig op på at være åbne og kunne bruges mange steder, imodsætning til Microsofts tidligere produkter.
-
0
-
0
Her er en ret god artikel der beskriver hvorfor nogen er imod OOXML. Umiddelbart er jeg overbevist om at der ikke kan komme meget brugbart ud af standarden, da dens fokus forekommer helt forkert.
http://www.ibm.com/developerworks/library/x-ooxmlstandard.html?ca=dgr-ln...
På den anden side har folk så travlt med at råbe "microsoft bashing", at der ikke kommer mange argumenter ud FOR OOXML. Hvorfor er standarden god? Hvorfor er den nødvendig, når vi har ODF? (Hvorfor må man ikke kritisere den, bare fordi den kommer fra Microsoft?)
-
0
-
0
Selvom Microsoft får OOXML igennem kan man stadigvæk kun bruge deres produkt i Windows, så lige her vil der ikke være nogen ændring.
-
0
-
0
Mark,
Selvom Microsoft får OOXML igennem kan man stadigvæk kun bruge deres produkt i Windows
Hmm - hvordan det?
Hvis du har nogle indvendinger imod OpenXML, der ikke allerede er addresseret, så skriv dem gerne til Dansk Standard. Det er vigtigt, at grundlaget for vores arbejde i Geneve bliver så godt som muligt.
-
0
-
0
Jeg taler ikke om OOXML (det er et format), men Word. Jeg tør ikke forholde mig mere til OOXML, end hvad allerede er derude, f.eks i den artikel jeg linkede til - som jo i øvrigt pænt illustrerer at et format der linker til lukkede rutiner selv er lukket.
-
0
-
0
Mark,
Jeg tør ikke forholde mig mere til OOXML, end hvad allerede er derude, f.eks i den artikel jeg linkede til - som jo i øvrigt pænt illustrerer at et format der linker til lukkede rutiner selv er lukket.
Har du husket at læse artiklen med kritisk sans og en snert af kildekritik?
-
0
-
0
Som sagt kan det være svært med den slags, når man kun får input fra det ene hold. Hvor tager han fejl?
-
0
-
0
Mark,
Som sagt kan det være svært med den slags, når man kun får input fra det ene hold.
Det er faktisk ikke rigtigt. Der foreligger jo en specifikation du kan checke eventuelle påstande i. Det er bestemt ikke raketvidenskab.
Hvor tager han fejl?
Jeg siger ikke, at han tager fejl - jeg har ikke læst hans artikel. Jeg spørger [i]dig[/i], om du har forholdt dig kritisk/teknisk til artiklen og evt fundet nogle fejl eller konstateret at alt var korrekt og sandt?
Sat lidt mere på spidsen: Besidder du den tekniske indsigt i OOXML (og evt ODF) til at forholde dig objektivt til artiklen? Artiklen er jo forfattet af en IBM-fyr, så det [i]kunne[/i] jo være, at artiklens konklusioner var farvet af dette.
(Faktisk er det et forsøgt på at hjælpe lidt - du skulle jo nødigt lave en "PHK".)
:o)
-
0
-
0
"I wanted to start by making one thing perfectly clear: I'm not an employee of IBM, these are my own opinions, and I developed these opinions without reference to the position of IBM on the issue."
Men altså, jeg faldt ikke over noget jeg syntes var decideret forkert. Men jeg har ikke brugt tid til at sætte mig ind i det, ud over at læse folks kommentarer. Og det virker som om han har styr på det. ;)
-
0
-
0
Mark,
"I wanted to start by making one thing perfectly clear: I'm not an employee of IBM, these are my own opinions, and I developed these opinions without reference to the position of IBM on the issue."
Ok - men alligevel bør du huske på, at der nok er en grund til, at den ligger på IBMs server.
Men altså, jeg faldt ikke over noget jeg syntes var decideret forkert. Men jeg har ikke brugt tid til at sætte mig ind i det, ud over at læse folks kommentarer. Og det virker som om han har styr på det. ;)
Men skal passe på med at lave den antagelse.
Men ok - jeg kigger på den. Som du måske har set, så har jeg en travl uge foran mig, så bær over med mig, hvis der går lidt tid inden jeg svarer tilbage.
-
0
-
0
Mark,
Her i ventetiden i Københavns lufthavn har jeg sat mig til at kigge på den artikel, som du refererede til. Jeg vil gerne understrege, at jeg faktisk har sat mig for at læse den med et åbent sind og jeg håbede lidt på, at jeg kunne konkludere "Jeg er sådan set enig med artiklens undersøgelser - men jeg er ikke enig i konklusionen".
Men det gik ikke helt sådan. Han optegner tre punkter, hvor han mener at OpenXML fejler, og lad mig kigge på de eksempler han bruger for at konkludere det han ønsker.
Unreasonable requirements:
Han taler om at fonte i forbindelse med sidehoveder/fødder i regneark kan angives med lokaliserede værdier (Part 4 afsnit 3.3.1.36). Han siger (og refererer til Stepháne R) at det giver et problem - for man kan ikke kende alle fonte i alle udgaver.
Det er jo sådan set korrekt - men jeg kan ikke se, hvad alternativet skulle være. Vær opmærksom på, at så snart vi begynder at anvende fonte i tekstdokumenter (og på hjemmesider) så bevæger vi os ud i et morads af mulige fejlkilder, da alle fonte ikke kan forventes at findes på alle platforme. Der findes heller ikke nogen liste man kan referere til, og hvis man ikke ønsker at lave en positiv-liste over fonte, der kan anvendes i et ODF- eller OpenXml-dokument (hvilket jeg bestemt ikke mener er en god idé), så er realiteterne desværre, at anvendelse af fonte på tværs af applikationer og platforme altid kan blive noget gris. Sådan er det med OpenXml og sådan er det med ODF.
Jeg vil også gøre opmærksom på, at der i de 35000 kommentarer fra de forskellige NSB'er ikke er en eneste, der har påpeget dette som et problem. Det er jo ikke nødvendigvis det samme som, at det ikke [i]er[/i] et problem, men der er masser af andre kommentarer til lige netop dette afsnit, så jeg vil antage, at hvis det havde været et reelt problem, så var der nok nogen, der havde skrevet til ISO/IEC om det.
Inadequate specifications
Han bruger VML som argument for, at man som 3.parts leverandør ikke kan implementere alt - men VML er netop specificefret i OpenXml-spec. Man kan selvfølgelig synes, at det er træls at skulle implementere det - men VML er fuldt specificeret. Han bruger også W3C-Schema-definitionen for xsd:string datatype (ST_String) som argument for, at "alt kan bruges i VML", men det er jo noget eklatant vås. Det er i den grad revet ud af kontekst. I sidste afsnit taler han om problemerne med, at et tekstformat har ét internt "drawing format" og at andre kontorpakker med andre tegneformater dermed skal eksportere disse til det nye interne format. Jeg ved ikke helt, hvad hans pointe er - men det er også sådan det foregår i ODF, hvor tegninger fra andre formater (som fx SVG) konverteres til det interne "OpenDocument Drawing"-format, så det er åbenbart sådan man gør med med ISO-certificerede dokumentformater.
Unique features
Her omtaler han de famøse compat-settings (de der WordWraplikeits1999-elementer). Problemet han påtaler er jo reelt nok - de var jo også en del af de danske kommentarer til OpenXml. Det pudsige er blot, at artiklen er fra 18. februar 2008, og på det tidspunkt havde det været generelt kendt i en måned, at disse elementer nu var fuldt specificerede. At han omtaler dem som stadigt værende problemer synes jeg er noget mystisk ... for nu at sige det mildt.
Han bruger så sine argumenter (som jeg mener er direkte forkerte) som grundlag for konklusionen om, at OpenXml ikke burde være en standard (i ISO). Det er jo fabelagtigt!
Inden han begynder at konkludere når han lige at fyre følgene af:
OpenXml er "a careful, bit-for-bit replication of Microsft's binary formats, wrapped up in angle brackets".
Tja - man kan jo være enig i dette eller lade være ... men for fanden ... det er jo hele idéen med OpenXml - nemlig at specificere de binære Microsoft Office filformater (i XML) og indgive dem til en standardiseringsorganisation. Det var jo det EU-kommissionen bad Microsoft om.
Mark, det er muligt, at du ikke arbejder med dette (dokumentformater, XML, XSLT, XML Schemas) hver dag - men jeg mener helt klart, at du ville have fundet i det mindste [i]nogle[/i] af fejlene herover - hvis du ville have læst artiklen med lidt kritisk sans.
:o)
-
0
-
0
Tja - man kan jo være enig i dette eller lade være ... men for fanden ... det er jo hele idéen med OpenXml - nemlig at specificere de binære Microsoft Office filformater (i XML) og indgive dem til en standardiseringsorganisation. Det var jo det EU-kommissionen bad Microsoft om
Hvorfor det?
Jeg vil stadigvæk hævde, at det havde været mest smart, om MS havde lavet en applikation, der kunne konvertere legacy DOC til nyt format, og så havde lavet en specifikation, der ikke var belemret med fortidens fejl, men var et format designet med nutidens viden og kompetencer!
-
0
-
0
michael,
Hvorfor det?
Som jeg siger - man kan være enig eller lade være.
-
0
-
0
Well, meget af det du kommer med er jo noget man kun kan vide, hvis man er godt inde i processen, og derfor er det ikke fejl jeg har været ops på.
Mht. fonte, så handler det som jeg ser det ikke om at selve fontene skal specificeres, men at måden man refererer til dem på kan være lokaliseret. Dvs. at man på ét tidspunkt kan have en perfekt implementering af OOXML, men en uge senere være ude af stand til at læse et fuldt ud standard-kompatiblet dokument fordi der er kommet en ny lokalisering. Der ville jeg nok mene at det var mere realistisk at holde sig til ét sprog - engelsk f.eks.
Hvad angår VML, så siger han at man skal bruge binaries til at fortolke det. At Microsoft har udgivet fulde specs på hvordan man selv implementerer disse kan jeg naturligvis ikke vide.
Endeligt er der spørgsmålet om det er en god ide at de blot har frigivet en specifikation af deres office format. Der kan man mene hvad man vil, siger du. Jeg vil så mene at det er et uhyre dårligt grundlag for et standard-format, at det i den grad tager hensyn til gamle formater og i det hele taget bærer rundt på en masse uhensigtsmæssigt arvegods fra fordums tid. Men det er måske ikke nok til at afholde det fra at blive til en standard...
-
0
-
0
Mark,
Well, meget af det du kommer med er jo noget man kun kan vide, hvis man er godt inde i processen, og derfor er det ikke fejl jeg har været ops på.
Næeh - det kræver jo noget indsigt at behandle disse ting teknisk. Det var også derfor jeg spurgte dig, om du havde denne.
Mht. fonte, så handler det som jeg ser det ikke om at selve fontene skal specificeres, men at måden man refererer til dem på kan være lokaliseret. Dvs. at man på ét tidspunkt kan have en perfekt implementering af OOXML, men en uge senere være ude af stand til at læse et fuldt ud standard-kompatiblet dokument fordi der er kommet en ny lokalisering. Der ville jeg nok mene at det var mere realistisk at holde sig til ét sprog - engelsk f.eks.
Jeg er sikker på, at hvis kravet for at angive en font i et dokument var, at navnet skulle skrives på engelsk, så ville der komme et ramaskrig fra de asiatiske lande. Ét af ISOs tre hovedprincipper er at standarder skal være kulturelt neutrale og dit forslag ville være imod dette princip.
Det drejer sig jo heller ikke om, at man ikke kan læse et dokument, hvis man ikke har fonten - men at dokumentet ser lidt mærkeligt ud. Den måde det håndteres på er jo som vi er vante til med fonte på hjemmesider, hvor man arbejder med fall-back fonte, hvis alt andet ikke virker. Jeg tror, at de fleste kender til CSS-koden
font-family: MyFont, Helvetica, Arial;
Det er ikke (teknisk anderledes) i OpenXml eller ODF.
Hvad angår VML, så siger han at man skal bruge (Microsoft, JLS) binaries til at fortolke det.
Ja, men det er forkert.
Jeg vil så mene at det er et uhyre dårligt grundlag for et standard-format, at det i den grad tager hensyn til gamle formater og i det hele taget bærer rundt på en masse uhensigtsmæssigt arvegods fra fordums tid. Men det er måske ikke nok til at afholde det fra at blive til en standard...
Nej - i hvert fald ikke i JTC1/ISO/IEC-sammenhænge. PDF er jo et skoleeksempel på det - den blev ISO-certificeret i slutningen af 2007.
-
0
-
0
Ifølge Andy Updegrove skulle det se sort ud for OOXML's godkendelse:
http://www.consortiuminfo.org/standardsblog/article.php?story=2008022905...
-
0
-
0
Tilføj kommentar
