Jesper Lund Stocholm bloghoved

168 måder at sige "Nej"

Som jeg tidligere har fortalt, er arbejdet med at gå implementeringen af de 168 danske kritikpunkter igennem nu startet. Konkret er det ORACLE Danmark og CIBER Danmark, der har tilbudt at lægge resourcerne i arbejdet og frem til januar 2009 vil vi sammen gå den endelige version af OOXML igennem.

Arbejdet er i høj grad møgkedeligt, for det er noget med at først kigge på det danske kritikpunkt, dernæst se svaret fra ISO, dernæst sammeholde det med eventuelle ændringer ved BRM-mødet i Geneve og til sidst bladre specifikationen og RelaxNG-schemas igennem for at verificere, at det er lavet korrekt.

Som eksempel kan jeg give det danske kritikpunkt DK-0011 (i den danske liste er det nummer 10). Et bud på gennemgangen kunne være:

DK #: DK-0011
ISO/IEC-Response: R-125
Original paragraph: Part 4, §2.15.3.26, pages 1,416?1,417
Current paragraph: Part 4, section 9.7.3.20, Part 1, section 17.15.1.21

Danish Comment:

There is no formal definition of the element footnoteLayoutLikeWW8 The suggestion to simulate the behaviour opens for a wide area of interpretation and introduce unwanted ambiguously to the specification, which will break the interoperability goals of the specification

Danish proposed solution:

The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification.

ISO/IEC Response:

Agreed; we will fully define the information necessary to implement this property (specified below). This description provides all of the information needed to mimic a behavior observed in a previously existing word processing application (Word 6.x/95/97). In addition, we will remove it from its current location in the specification (Part 4, §2.15.3.26, pages 1,416?1,417), and place it into a new annex for deprecated features.

Analysis:

In Part 4, section 9.7.3.20 the proposed text has been added. In addition the element has been removed from the strict schema and now only resides in the transitional schema for Part 4 (wml.rnc). The element has been removed from the list of child-elements for the element in Part 1, section 17.15.1.21.
Conclusion: Danish comment has been addressed.

Jeg bliver sgu helt tør i halsen blot ved at skrive denne smule tekst.

... og det er her du kommer ind i billedet.

OOXML er desværre ikke blevet offentlig tilgængelig endnu, og derfor kan vi ikke give adgang til den. Men det er ikke det samme som, at du ikke kan hjælpe med at verificere, om kommentarene er blevet rigtigt sat ind.

Jeg har lavet en indledende gennemgang af de danske svar (listen kan ses på Dansk Standards hjemmeside) for at lave en overordnet gruppering af svarene samt en vurdering af, om det bliver svært eller let at verificere implementeringen. Svarene fra ISO/IEC kan bla. findes via ooxml.org .

Indtil videre ser min liste således ud:

VML

DK-0006, DK-0007, DK-0008, DK-0009, DK-0022, DK-0038, DK-0095

Billeder

DK-0023, DK-0028, DK-0077, DK-0083, DK-0084, DK-0087, DK-0089

Datoer (*)

DK-0033, DK-0136, DK-0137, DK-0166

Bitmasker (*)

DK-0037, DK-0108, DK-0109, DK-0110, DK-0111, DK-0112, DK-0116, DK-0117, DK-0132, DK-0147

Funktioner (Regneark) (*)

DK-0056, DK-0138, DK-0162, DK-0163, DK-0164, DK-0165

ISO-sprog

DK-0076

Diverse

DK-0075 (Layout), DK-0160 (DEVMODE)

Sikkerhed (*)

DK-0114, DK-0139

Units (enheder) (*)

DK-0140, DK-0143

Punkterne markeret med en stjerne er de, hvor jeg positivt ved, at der blev lavet omfattende ændringer på BRM-mødet i Geneve. Dokumenterne fra Geneve kan ses på Alex Browns hjemmeside.

Jeg har helt sikkert overset noget ovenfor og derfor vil vi/jeg bede om jeres hjælp til denne overordnede kategorisering. så hvis du mener, at det er vigtigt at få verificeret om den danske kritik er slået igennem i den endelige standard, så giv en hånd med her. Du kan blot skrive i dette kommentarspor, så opdaterer jeg løbende listen.

Tanken med arbejdet er, at hvis/når vi finder punkter, der ikke er indarbejdet i standarden, så laver vi i DS en "defect report" (ligesom japanerne gjorde) og den tager jeg "med under armen", når jeg rejser til det første arbejdsgruppemøde sidste i januar.

Kommentarer (24)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jacob Christian Munch-Andersen

Jeg har givet op på forhånd, netop en funktion som den der vidner i allerhøjeste grad om at skaberne af OOXML ikke har forsøgt at kreere en brugbar standard. At rette i OOXML er ligesom at forsøge at reparere en totalsmadret bil, det tager meget mere arbejde end at lave en ny, og det bliver alligevel aldrig rigtigt godt.

  • 0
  • 0
Eskild Nielsen

På det berømte/berygtede møde hos DS i marts, hvor den danske beslutning skulle anbefales, var der som bekendt mange der talte imod at støtte OOXML.

Der var flere grunde, men 2 der blev nævnt med styrke var dels at svarene ikke var fyldestgørende, og dels at vi ikke kunne nå at kontrollere at de rent faktisk blev indføjet.

Tilhængerne kunne ikke se problemerne med svarene.

Modstanderne kan enten bruge energi på at kontrollere at de ændringer, som de ikke syntes var store nok er kommet ind korrekt, eller de kan mene det hele kan være lige meget nu, og dermed risikere at tabe det lidet, de havde vundet.

/esni

  • 0
  • 0
Jesper Lund Stocholm Blogger

Eskild,

Modstanderne kan enten bruge energi på at kontrollere at de ændringer, som de ikke syntes var store nok er kommet ind korrekt, eller de kan mene det hele kan være lige meget nu, og dermed risikere at tabe det lidet, de havde vundet.

Det lyder som om du mener, at det er en loose/loose-situation for modstanderne af OOXML, men det er jeg ikke enig i. Jeg kan kun tilslutte mig Henrik Madsen fra DTU, der på sidste møde udtalte, at vi i udvalget har en forpligtelse til at kigge svarene igennem og sammenligne dem med den endelige udgave af OOXML.

Har du lyst til at hjælpe til (eller andre fra DKUUG)? Du kan jo dermed få den liste over sammenhængen imellem de danske kommentarer og ISO/IECs svar, som du efterlyste efter BRM tidligere i år.

  • 0
  • 0
Henrik Jensen

Modstanderne kan enten bruge energi på at kontrollere at de ændringer, som de ikke syntes var store nok er kommet ind korrekt, eller de kan mene det hele kan være lige meget nu, og dermed risikere at tabe det lidet, de havde vundet.

For mig at se handler det jo også om ikke at lægge for stor vægt på godkendelsen men derimod den vedligeholdelse som nu skal være med til at forbedre standarden yderligt.

Det samme har jo gjort sig gældende for ODF selvom den faktisk slet ikke vedligeholdes i ISO. Da ODF 1.0 blev godkendt i ISO var det jo med ganske få kommentarer, 6-7 stykker hvis jeg husker rigtigt. Siden hen er ISO jo på kommet op med en defects liste med langt flere punkter til ODF 1.0 og som OASIS er tæt på eller har (kender ikke status) indarbejdet i et officiel errata dokument til ODF 1.0

Så værdien af ISO i forhold til at forbedre ODF standarden har altså været større efterfølgende end i forbindelse med selve godkendelsen og det på trods af at ISO ikke står for vedligehold.

Ingen tvivl om at OOXML nok er blevet kigget en del bedre efter i sømmene end ODF 1.0 blev det i sin tid i forbindelse med godkendelsesarbejdet, men det er ikke ensbetydende med at selve vedligeholden ikke bliver mindst lige så vigtig hvis ikke vigtigere end selve godkendelsen.

  • 0
  • 0
Anders Olsen

For mig at se handler det jo også om ikke at lægge for stor vægt på godkendelsen men derimod den vedligeholdelse

Sikke dog en holdning...

*Bare giv ham certificeringen, så kan han altid lære stoffet bagefter *Bare gift dig med hende, og lær og elske hende bagefter *Bare køb bilen, så kan du altid reparere skaderne bagefter

Find selv på flere.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Henrik,

For mig at se handler det jo også om ikke at lægge for stor vægt på godkendelsen men derimod den vedligeholdelse som nu skal være med til at forbedre standarden yderligt.

Som Anders er jeg ikke helt enig. Det drejer sig ikke om at godkendelsen i sig selv ikke var væsentlig - det kan jeg love dig for, at den var.

Pointen er derimod, om vedligehold af OOXML er vigtig eller ej. Hvis man synes den er vigtig, så har man her muligheden for at bidrage til, at der sker noget.

Hvis man derimod ikke synes, at vedligehold af OOXML er vigtig, så behøver man jo ikke tænke på, om de 168 danske kommentarer til OOXML rent faktisk er kommet med i standarden.

Mange af de 168 kommentarer var jo i øvrigt netop møntet på, at det skulle være nemmere for andre end Microsoft at implementere OOXML - men hvis man ikke mener, at det er vigigt, så er det jo ikke vigtigt.

  • 0
  • 0
Eskild Nielsen

Mange af de 168 kommentarer var jo i øvrigt netop møntet på, at det skulle være nemmere for andre end Microsoft at implementere OOXML - men hvis man ikke mener, at det er vigigt, så er det jo ikke vigtigt.

Det var lige det jeg mente med den indre dialektik i situationen.

Nu da vi har standarden er det vigtigt at sikre at teksten er i overenstemmelse med det der rent faktisk blev aftalt.

Hvis ikke man gør det, så bliver det heller ikke muligt at arbejde for de udvidelser, forbedringer og ændringer, som alle levende standarder får i deres levetid.

/esni

  • 0
  • 0
Henrik Jensen

*Bare køb bilen, så kan du altid reparere skaderne bagefter

Men at sammenligne komplekse standarder med biler, er efter min mening også meget svært.

Det handler jo om hvad man vil opnå i den sidste ende. Hvad vi efter min mening ønsker at opnå med standarder som f.eks. ODF eller OOXML er at de kan implementeres af alle og at der er inteoperabilitet mellem de forskellige implementationer. Hvis jeg køber en bil så er hvad jeg ønsker at opnå måske at jeg ikke skal tage offentlige transport frem og tilbage fra arbejde hver dag.

Hvis man køber en bil så er det fair at forvente at den er rimelig fejlfri og altså fair at forvente at man faktisk opnår sit mål med det samme. Hvis man godkender en kompleks standard som f.eks. ODF eller OOXML og tror at så er arbejdet færdigt og så har vi opnået vores mål så er det utroligt naivt.

Tag ODF som eksempel. Den har i version 1.0 vel været godkendt i OASIS i ca. 3½ år nu og i ISO i 2½ år. Har den opnået sit mål?: Nej der er stadig en hel del interoperabilitetsproblemer mellem de fleste implementationer af standarden der ikke bygger på samme kodedatabase. Gør det samme sig gældende for OOXML? Ja da.

Nu handler interoperabilitetsproblemer selvfølgelig ikke kun om standarden men også om implementationerne og almindelige menneskelige fejl, men igen når implementationer ender op forskelligt så kan det mange gange også være udtryk for manglende præcision i standarden.

Så spørgsmålet er hvornår at man skal godkende en standard? Er det først når vi ved at den er 100% perfekt og at vores mål om at opnå interoperable implementationer af standarden så er opnået/kan opnås?

Det mener jeg ikke.

Det betyder selvfølgelig ikke at godkendelsen skal være rent "stempel-arbejde" og det har det efter min mening heller ikke været med OOXML, der er rigtig mange mennesker som har lagt rigtig mange timer i at forbedre standarden op til godkendelsen. Men det betyder at hvis man så bare sætter sig tilbage nu og siger "når nu er den godkendt så er der ikke mere vi kan gøre", så er chancen for at vi nogensinde opnår målet med mange interoperable implementationer af standarden efter min mening meget meget små.

  • 0
  • 0
Jacob Christian Munch-Andersen

Helt ærligt ja, en standard skal fandme være i orden når den godkendes af ISO eller lignende. Ikke at der ikke skal være plads til at rette kommaer bagefter, men den skal opfylde målet i godkendelsesøjeblikket.

Når Microsoft lægger underlige udokumenterede legacy koder i standarden, så er det en ommer, Microsoft har ikke gjort hjemmearbejdet godt nok, og jeg kan ikke se det rimelige i at andre mennesker skal spilde deres tid på at udpensle alle de små ting som åbenlyst er gjort forkert.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Jacob,

Helt ærligt ja, en standard skal fandme være i orden når den godkendes af ISO eller lignende. Ikke at der ikke skal være plads til at rette kommaer bagefter, men den skal opfylde målet i godkendelsesøjeblikket.

Så jeg kan konkludere, at du synes de indvendinger, der kom mod ODF da den blev sendt til ISO, ikke var "vigtige" eller "essentielle" nok? Er der en øvre grænse for, hvornår du mener, at en "fejl" er stor nok til at kunne bremse en godkendelse?

Når Microsoft lægger underlige udokumenterede legacy koder i standarden, så er det en ommer

Der var/er også udokumenterede elementer og applikationsspecifik opførsel i ODF - men når nu de "udokumenterede legacy koder" nu er blevet dokumentarede - så er det vel ikke noget problem længere?

  • 0
  • 0
Jacob Christian Munch-Andersen

Jeg har ikke nævnt ODF, så hvordan du konkluderer noget om min holdning til de spørgsmål er mig en gåde.

Er der noget galt i at synes at ODF er noget lort og OOXML er værre?

I øvrigt synes jeg ikke at legacy koder i stil med "behave like XX program" er i orden uanset hvor veldokumenterede de måtte være, det er noget rod uden lige og hører ingen steder hjemme i en ægte fri/åben standard.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Jacob,

Jeg har ikke nævnt ODF, så hvordan du konkluderer noget om min holdning til de spørgsmål er mig en gåde.

Er der noget galt i at synes at ODF er noget lort og OOXML er værre?

Jeg synes blot, at det er interessant at høre for første gang, at der rent faktisk er nogen, der mener at ODF ikke burde have været godkendt.

At ODF er noget lort er jeg slet ikke enig - og den har helt klart sin berettigelse som ISO-standard (ligesom OOXML), men det er bestemt ikke det samme som at ODF er en god standard eller at ODF på en eller anden måde skulle regnes som et eksempel til fremtidig følge i standardisering.

I øvrigt synes jeg ikke at legacy koder i stil med "behave like XX program" er i orden uanset hvor veldokumenterede de måtte være, det er noget rod uden lige og hører ingen steder hjemme i en ægte fri/åben standard.

Det er jo en afvejning man hver især må gøre sig. Jeg vil dog fastholde, at din konklusionsvej er forkeret. ODF og OOXML er jo begge eksempler på "ægte, åbne og fri" standarder, men i begge er der både applikationsspecifik opførsel (altså formuleringer som "behaviour is application defined") samt udokumenterede hjørner, hvor specifikationen ikke giver nogen hjælp til, hvordan et givet element eller dets værdi skal fortolkes.

Men det gør hverken ODF eller OOXML mindre "ægte, åbne og fri".

  • 0
  • 0
Henrik Jensen

Helt ærligt ja, en standard skal fandme være i orden når den godkendes af ISO eller lignende. Ikke

Men hvordan definerer du iorden på noget der så komplekst?

Mener du at ODF har opnået målet her 2½ efter godkendelsen i ISO?

Kan jeg lave et vilkårligt ODF dokument i OOo sende det til en kollega som benytter KOffice til kommentering som herefter sender det videre til kunden som benytter Google Docs for endelig revision, og så kan vi være forholdsvis sikre på at vi ikke mister information undervejs?

Når Microsoft lægger underlige udokumenterede legacy koder i standarden, så er det en ommer,

Nu tror jeg faktisk at de fleste legacy ting i OOXML er blevet specificeret i forbindelse med godkendelsen og mange er vel tilmed lagt over i en Transitional part som man jo ikke nøvendigvis behøver at implementere hvis man er fuldt tilfreds med kun at understøtte det som ligger i Strict.

Og når vi snakker om legacy ting. Sun har jo f.eks. valgt at placere deres legacy ting (ved ikke om det er dem alle) i en OOo specifik udvidelse af ODF. Så på den vis er det jo pænt fordi at det ikke står i standarden, men øger det muligheden for interoperabilitet (altså vores egentlige mål med at havde standarden) at man skal over og kigge i kildekoden til OOo hvis man gerne vil understøtte disse legacy ting?

  • 0
  • 0
Jesper Lund Stocholm Blogger

Henrik,

Og når vi snakker om legacy ting. Sun har jo f.eks. valgt at placere deres legacy ting (ved ikke om det er dem alle) i en OOo specifik udvidelse af ODF. Så på den vis er det jo pænt fordi at det ikke står i standarden, men øger det muligheden for interoperabilitet (altså vores egentlige mål med at havde standarden) at man skal over og kigge i kildekoden til OOo hvis man gerne vil understøtte disse legacy ting?

Til orientering har vi nu også fået den mulighed i OOXML, hvor der er kommet et nyt element "til verden", der specifikt er møntet på, at andre implementeringer af OOXML end Microsoft Office skal have mulighed for at gemme applikationsspecifikke indstillinger.

... so now we're fucked either way ... :o(

  • 0
  • 0
Jesper Lund Stocholm Blogger

I kan lige få den del af undersøgelsen, der omhandler netop dette element:

[b]DK #:[/b] DK-0017 [b]ISO/IEC-Response:[/b] R-131 [b]Original paragraph:[/b] Part 4, section 2.15.3.54, Page 1469 [b]Current paragraph:[/b] Part 1, section 17.15.3.4 [b]Danish Comment:[/b] The element uiCombat97to2003 is a construct which is intended to "disable UI function that is not compatible with word 97-2003" Since the only company who have the actual knowledge about, which UI function isn't compatible with Microsoft Word 97 is the owner of the application, this element only make sense for that owner. Since Word97-2003 is not clearly defined, i guess this means Microsoft Word 97, since the introduction declare, that backward compatibility with Microsoft Office application is one of the intended goals of the ECMA.376 Office Open XML specification. This means that the element uiCombat97to2003 is a specific element, which only purpose is to let Microsoft, the owner of Microsoft office, build features in the specification, which can't be delivered by any other application developer. If this is correct, then Microsoft is the only company who can provide a complete and correct implementation of the ECMA-376 Office Open XML specification [b]Danish proposed solution:[/b] The intended behaviour / semantic of the tag should be defined in an unambiguously way in the specification or removed from the specification. Also insert information used in other compability settings (...) [b]ISO/IEC Response:[/b] Agreed; this property is not part of the legacy binary document format and only affords for the settings of a specific vendor. Accordingly, the following changes will be made: •This property will be removed from the specification •An affordance will be created for individual applications, such as OpenOffice or WordPerfect, to create custom compatibility settings [b]Analysis:[/b] The element has been removed from the list of child-elements for the element in Part 1, section 17.15.1.21. The new element has been added to section 17.15.3.4. This element exists in the strict as well as transitional schemas.

Læg mærke til, at elementet eksisterer i både den fremadrettede del samt den bagudrettede del. Det er sgu noget hø, for hvor "transistional" tidligere betød, at man "håndterede gamle dage", så er det nu også muligt at putte dette i "strict" mode.

Og jo - jeg vil helt klart gerne benytte lejligheden til at undskylde, at den er røget under min radar i forbindelse med arbejdet i DS.

  • 0
  • 0
Henrik Jensen

Til orientering har vi nu også fået den mulighed i OOXML

Lad os håbe det ikke bliver misbrugt for meget så. Jeg mener at desto flere applikationsspefikke settings de enkelte implementationer benytter (som vel og mærke har indflydelse på præsentation af et dokument) desto mere mister standarden sin værdi i forhold til at sikre fuld interoperabilitet.

... so now we're fucked either way ... :o(

Jeg tror bare at konklusionen er at det at opnå fuld interoperabilitet mellem dokumentstandarder det er bare ikke nogen nem opgave.

  • 0
  • 0
Jacob Christian Munch-Andersen

Jesper, det kan være fint nok at der ting som standarden med overlæg gør valgfrie, især ifht. visningen af dokumentet er der ting som standarden ikke bør blande sig i. Noget helt helt andet er at lave et shorttag som ændrer på alle mulige ting for at gøre det lettere at konvertere gamle dokumenter, vi slipper aldrig af med underlig Word 97 legacy mm. på den måde.

Henrik, tag lige og læs indlæggene i debatten før du svarer. Jesper har allerede forsøgt at gøre mig til ODF fanboy, hvilket jeg har svaret på.

Til orientering har vi nu også fået den mulighed i OOXML, hvor der er kommet et nyt element "til verden", der specifikt er møntet på, at andre implementeringer af OOXML end Microsoft Office skal have mulighed for at gemme applikationsspecifikke indstillinger.

Det synes jeg nu ikke er så slemt, mange programmer har nogle indstillinger som det er bedst at gemme sammen med dokumentet selv, men som ikke er kritiske ifht. visning or redigering. Så længe det ikke bliver misbrugt er der intet galt i sådan et element.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Jacob,

Jesper, det kan være fint nok at der ting som standarden med overlæg gør valgfrie, især ifht. visningen af dokumentet er der ting som standarden ikke bør blande sig i

Desværre er disse ting ikke kun relaterede til visning af dokumenter men også ifht anvendelse af hash-funktioner, rendering af tabelstrukturer og lignende. Det nytter ikke at nedtone problemet - det [u]er[/u] et problem - uanset hvordan du vender og drejer det.

Det synes jeg nu ikke er så slemt, mange programmer har nogle indstillinger som det er bedst at gemme sammen med dokumentet selv, men som ikke er kritiske ifht. visning or redigering. Så længe det ikke bliver misbrugt er der intet galt i sådan et element.

Det er muligt at du ikke er en ODF-fanboy, men din udtalelse er desvære karakteristisk for kombinationen af en "ODF-fanboy" og en "anti-OOXML-boy".

På den ene side kritiseres OOXML for en eller anden obskur egenskab og netop denne ene egenskab gøres til et kardinalpunkt og grund til at smide hele lortet på møddingen. Når jeg så påpeger, at ODF har selvsamme egenskab, så negligeres det og man påpeger, at "joeh, men principielt er der jo ikke noget i vejen med det - så længe det ikke misbruges".

Problemet i konklusionsrækken er blot, at dette "blue-sky-scenario" er fuldstændigt urealistisk. Al erfaring viser os nemlig, at når der er en mulighed for at bruge et eller andet på en anden måde end tiltænkt, så bliver det gjort (misbrugt). Det bedste eksempel på dette er jo "reference-implementeringen" af ODF, nemlig OOo. Listen over applikationsspecifikke attributværdier for den er alen lang - og en lang række af dem har betydning for det visuelle layout for dokumenterne.

Som et klasse-eksempel på dette er attributten "UseFormerLineSpacing" eller "UseFormerObjectPositioning". Her kan man slå op i Suns API-dokumentation for OOo og se, at det betyder, at man skal opføre sig som "OpenOffice.org 1.1".

http://api.openoffice.org/docs/common/ref/com/sun/star/text/DocumentSett...

... og så er problemet jo "reduceret" til at prøve at hitte ud af, hvilken trunk af OOos kildekode, der udgjorde grundlaget for OOo 1.1.

Så dit udsagn "så længe det ikke bliver misbrugt er der intet galt i sådan et element" er i bedste fald ren, naiv eskapisme ... eller også laver du en "Nelson" og sætter bevidst kikkerten for det blinde øje.

i[/i]

  • 0
  • 0
Henrik Jensen

Henrik, tag lige og læs indlæggene i debatten før du svarer. Jesper har allerede forsøgt at gøre mig til ODF fanboy, hvilket jeg har svaret på.

Det er så en fejl i mine kommentarer hvis du har fået den opfattelse.

Jeg argumenterer bare for at vi hverken med ODF eller OOXML er bare tætte på det egentlige mål, og derfor ud fra din definition burde ingen af dem være blevet godkendt i ISO.

Og så sætter jeg spørgsmåltegn ved om det ville hjælpe os at hverken ODF eller OOXML var blevet ISO godkendte men at Sun/IBM og Microsoft bare for sig selv arbejdede viderede de næste mange år frem med henholdsvis ODF og OOXML uden at andre kunne få indflydelse. Jeg tror ikke at vi ville være kommet hurtigere tættere på målet med den fremgangsmåde. Den eneste fordel jeg kunne se var så at folk så ikke fejlagtigt fik den opfattelse at nu hvor standarderne var godkendte så er målet automatisk opnået.

mange programmer har nogle indstillinger som det er bedst at gemme sammen med dokumentet selv, men som ikke er kritiske ifht. visning or redigering. Så længe det ikke bliver misbrugt er der intet galt i sådan et element.

Problemet er at i f.eks. OOo applikationsspecifikke settings er der også en hel del settings som har indflydelse på visning og redigering, og jeg frygter at det samme vil ske med elementet i OOXML.

  • 0
  • 0
Jørgen Elgaard Larsen

Selvom jeg ikke er den store tilhænger af OOXML, ville jeg gerne hjælpe med at gå de 168 punkter igennem.

Men jeg har nu svært ved at holde humøret oppe, når DS og især ISO lægger den ene hindring efter den anden i vejen for, at man kan bidrage til processen.

Jeg forstår virkelig ikke, hvorfor ISO nægter at udgive den foreløbige specifikation af OOXML. Man får uværgeligt det indtryk, at de slet ikke er interesserede i at få offentlighedens hjælp til at skabe en bedre standard.

Det er svært at opfatte OOXML som standardiseret og vedligeholdt i et åbent forum via en åben proces.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Jørgen,

Selvom jeg ikke er den store tilhænger af OOXML, ville jeg gerne hjælpe med at gå de 168 punkter igennem.

Det lyder rigtigt dejligt - og rart at ikke alle er blevet skræmt væk af debatten i mit sidste blogindlæg.

Der er følgende konkrete opgave, som du kan hjælpe med: Mapningen imellem de danske kommentarer og listen på de 1027 svar fra ISO.

Listen over danske kommentarer findes på http://www.ds.dk/da-DK/ydelser/Standardisering/S-udvalg/S-445/Documents/...

Listen over ISOs svar findes på http://www.noooxml.org/forum/t-36002/the-2293-pages-of-the-ecma-comments... . Det er godt nok ikke et officielt dokument, men vi overlever nok.

I forbindelse med det stykke arbejde ORACLE og CIBER arbejder på pt har vi behov for en liste som følger:

Dansk kommentar --> ISO-svar DK-23 --> Response XXXX DK-167 --> Response YYYY

Har du lyst til at slå dig løs med det?

Jeg forstår virkelig ikke, hvorfor ISO nægter at udgive den foreløbige specifikation af OOXML. Man får uværgeligt det indtryk, at de slet ikke er interesserede i at få offentlighedens hjælp til at skabe en bedre standard.

Jeg er enig med dig i, at det er utilfredsstillende, at vi ikke har den endelige version af OOXML frigivet endnu. Men teknisk (fnis) set er det ude af ISOs hænder og er i ITTFs hænder. De skal bla. have sat en ny forside på standarden og andre småting, og inden da kan den ikke udsendes. Jeg har ingen anelse om hvorfor det tager så lang tid, men også for ODFs vedkommende tog det lang tid - ikke mindre end 6 måneder - så det er åbenbart ikke noget særsyn.

Dette var i øvrigt én af de ting, der blev kritiseret højlydt af ECMA ved mødet jeg deltog i i London i sommeren 2008. De mente - som du og jeg - at det var utilfredsstillende, at en færdig standard ikke kunne offentliggøres før laaaaang tid efter arbejdet var ovre og at man risikerede at miste "time-to-market", hvis den ikke blev tilgængelig "med det samme". De ønskede konkret at offentliggøre den via eget website med det vuns. Her var det faktisk ISO (eller, SC34), der måtte fortælle ECMA, at der er nogle regler, der skal overholdes, hvis man vil have ISO-stemplet, så de smækkede til sidst hælene sammen og sagde "Jawohl".

:o)

  • 0
  • 0
Jesper Lund Stocholm Blogger

Nå, nu lavede jeg sgu selv listen :-)

Den ser således ud:

DK # ISO/IEC Response # DK-0001 10 DK-0002 975 DK-0003 973 DK-0004 44 DK-0005 44 DK-0006 96 DK-0007 96 DK-0008 96 DK-0009 96 DK-0010 122 DK-0011 125 DK-0012 126 DK-0013 127 DK-0014 128 DK-0015 129 DK-0016 130 DK-0017 131 DK-0018 124 DK-0019 123 DK-0020 132 DK-0021 133 DK-0022 96 DK-0023 64 DK-0024 16 DK-0025 474 DK-0026 65 DK-0027 48 DK-0028 71 DK-0029 48 DK-0030 102 DK-0031 425 DK-0032 624 DK-0033 43 DK-0034 169 DK-0035 187 DK-0036 83 DK-0037 135 DK-0038 83 DK-0039 475 DK-0040 475 DK-0041 34 DK-0042 4 DK-0043 46 DK-0044 487 DK-0045 487 DK-0046 487 DK-0047 139 DK-0048 139 DK-0049 139 DK-0050 139 DK-0051 139 DK-0052 139 DK-0053 691 DK-0054 210 DK-0055 460 DK-0056 167 DK-0057 491 DK-0058 92 DK-0059 6 DK-0060 6 DK-0061 6 DK-0062 6 DK-0063 6 DK-0064 692 DK-0065 346 DK-0066 350 DK-0067 346 DK-0068 468 DK-0069 459 DK-0070 646 DK-0071 351 DK-0072 454 DK-0073 201 DK-0074 190 DK-0075 457 DK-0076 1 DK-0077 481 DK-0078 453 DK-0079 488 DK-0080 489 DK-0081 693 DK-0082 611 DK-0083 455 DK-0084 456 DK-0085 192 DK-0086 694 DK-0087 492 DK-0088 618 DK-0089 106 DK-0090 113 DK-0091 386 DK-0092 477 DK-0093 275 DK-0094 696 DK-0095 92 DK-0096 472 DK-0097 971 DK-0098 972 DK-0099 47 DK-0100 86 DK-0101 140 DK-0102 87 DK-0103 88 DK-0104 639 DK-0105 14 DK-0106 142 DK-0107 210 DK-0108 135 DK-0109 135 DK-0110 135 DK-0111 135 DK-0112 135 DK-0113 15 DK-0114 102 DK-0115 144 DK-0116 135 DK-0117 135 DK-0118 42 DK-0119 53 DK-0120 166 DK-0121 1023 DK-0122 612 DK-0123 613 DK-0124 959 DK-0125 959 DK-0126 959 DK-0127 16 DK-0128 1019 DK-0129 614 DK-0130 697 DK-0131 698 DK-0132 135 DK-0133 642 DK-0134 695 DK-0135 103 DK-0136 43 DK-0137 43 DK-0138 180 DK-0139 102 DK-0140 137 DK-0141 64 DK-0142 16 DK-0143 362 DK-0144 37 DK-0145 65 DK-0146 282 DK-0147 135 DK-0148 83 DK-0149 34 DK-0150 995 DK-0151 140 DK-0152 142 DK-0153 43 DK-0154 34 DK-0155 92 DK-0156 140 DK-0157 83 DK-0158 40 DK-0159 42 DK-0160 142 DK-0161 25 DK-0162 26 DK-0163 27 DK-0164 30 DK-0165 24 DK-0166 18 DK-0167 16 DK-0168 1020

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