WG4 arbejdsgruppemøde i Paris (OOXML)

I starten af december måned mødtes de udpegede eksperter i arbejdsgruppen ansvarlig for IS29500s vedligehold til nogle intensive face-to-face dage i Paris.

Jeg ser altid frem til disse dag, for vi får virkeligt noget arbejde fra hånden - og udgiftsmæssigt gjorde det jo bestemt heller ikke noget, at der ikke var så lang til Paris ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=") .

(referatet kan hentes fra vores SVN-repository)

Vi havde en omfattende dagsorden foran os - med tre store klumper:

Disposition of comments for COR1

Vores arbejde i arbejdsgruppen i 2009 har været fokuseret på at få sammensat to sæt rettelser/tilføjelser til OOXML - nemlig COR1 og AMD1. COR1 (Corrigendum 1) består primært af de mest trivielle rettelser, dvs stavefejl i specifikationen, prosa-ændringer og andre ting, som vi har vurderet ville give mindst problemer for eksisterende applikationer, der understøtter IS29500. AMD1 (Amendment 1) er de lidt større ændringer, der havde større udsigt til at kunne lave ravage for eksisterende applikationer. De to sæt dokumenter blev færdiggjort ved mødet i København i sommer 2009, og afstemningerne om dem havde deadline hhv. 4. november (COR1) og 4. december (AMD1).

COR1-sættene (ét for hver part i OOXML) blev heldigvis godkendt med et absolut minimalt antal nej-stemmer, men der blev indsendt en del kommentarer, og det land, der stemte "nej" (Brasilien), havde indikeret, at man ville ændre stemmen til "Ja", hvis kommentarene blev imødekommet.

Alt i alt var der 161 kommentarer, men de fleste var enslydende og kunne besvares med samme svar. Vi brugte dog alligevel godt og vel en hel dag på at gennemgå kommentarene og finde på korrekte svar.

En COR-afstemning i JTC1-sammenhænge er en "SC34-afstemning", så da den gik rent igennem, er IS29500 i dag at regne for "IS29500:2008 + errata". Vi snakkede på mødet om, at der er forskellig praksis for publicering af COR-materiale. Der er nogle standarder, hvor man først sender dem til "print" ved ITTF efter 2 eller 3 COR-sæt, men vi valgte at sende vores COR-sæt til print med det samme hos ITTF. Derfor vil man om føje tid kunne hente listen over rettelser med fin ISO/IEC-forside og alt muligt.

AMD1-afstemningen gik også igennem på samme vis (med samme mængde "Nej"-stemmer), men da det her drejer sig om en "Amendment", så er der udover SC34-afstemningen også en JTC1-afstemning, der skal overstås. Jeg har ikke lige datoen for deadline for denne afstemning, men jeg regner med, at det sker inden næste arbejdsgruppemøde i Stockholm i slutningen af marts 2010.

Diskussion af "S vs T"

Alex Brown har indtil flere gange holdt en præsentation omkring forholdet imellem S og T, og dette møde var ingen undtagelse. Præsentationen skulle danne afsæt til en diskussion af, hvordan vi skulle forholde os til S og T - og hvordan de i fremtiden skal udvikles.

For at starte diskussionen, nedskrev vi en række spørgsmål, som kunne inspirere os til en frugtbar samtale.

(som et lille kuriosum kan nævnes, at vores convenor (Murata Makato) ikke selv ledede denne diskussion, da han (og Japan) har en meget fast holdning til udviklingen af disse schemas (nemlig at der løbende skal tiføjes ny funktionalitet til både S og T). Derfor deltog han i diskussionen som "almindelig ekspert" og SC34-formanden Sam Oh fra Korea tog over for ham)

Nogle af disse spørgsmål var:

• Given that it was the intention of the BRM that T not apply to new documents, what constitutes a new document'
• Do we want to encourage migration from T to S' If so, what do we mean by migration, and why do we wish to encourage it'
• In order to encourage migration to S, should we freeze T'
• Should we abandon S'
• Do we intend that the already-published schemas for T never change except for bug fixes'
• Do we intend that the already-published schemas for S never change except for bug fixes'
• Do we want to remove ISO 8601 dates as SpreadsheetML cell values from T'
• Do we want to add serial dates to S?

Vi brugte nogle timer på at snakke om disse ting, og det var dette emne, der optog os mest, når vi spiste morgenmad, frokost, aftensmad, drak øl etc.

Vi kom ikke til en endelig beslutning, men vi opnåede fremdrift på en række punkter. Vi diskuterede bla. muligheden for at anvende MCE til vores egne tilføjelser til OOXML. Dette var helt nyt for mig, for jeg har altid set MCE som et værktøj for leverandører, der ønskede at udvide OOXML. At vi selv skulle bruge det til vores eget brug havde jeg ikke tænkt på, men det er umiddelbart en super god idé. Vi diskuterede også den famøse "fastfrysning af T". Jeg er af den holdning, at vi skal fastfryse T og kun lave udvidelser til S, og dette spørgsmål ligger direkte i punkterne 5) og 6) ovenfor. Vi nåede ikke at blive helt færdige med diskussionerne, men vi fik nikket rundt om hele bordet til den holdning, at vi skulle fastfryse "core schemas" for T og måske, på et eller andet tidspunkt, udvide "core schemas" for S. Det er min klare forventning, at vi når en endelig afklaring i foråret, men indtil videre er jeg optimistisk - al den stund, at vi jo faktisk landede på en holdning, der modsvarer min egen 100%.

Diskussion af "ISO-datoer"

Mange af diskussionerne ved BRM og i hele DIS-processen bar desværre præg af, at de fleste kloge hoveder havde "tekstdokumenter" som hovedområde og ikke regneark eller præsentationer. Derfor var nogle af de beslutninger vi tog ikke helt optimale for specifikt regneark.

I WG4 har vi en deltager fra dataanalysefirmaet Monarch, der laver integrationsløsninger og datamining for stort set hver eneste datakilde, man kan forestille sig - og derfor naturligvis også regneark. De har haft understøttelse af OOXML (regneark) nærmest fra "Dag 1", og hvis nogen "lives and breathes spreadsheets", så er det gutterne fra Monarch. Deres arbejde i gruppen på opstramning af tekst i standarden samt funktionalitet i den har været uvurderligt, og deres repræsentant Gareth Horton har igennem længere tid arbejdet sammen med én af Microsofts Excel-eksperter omkring kvalificering af "ISO-datoer" i OOXML. ISO-datoer blev nærmest smidt ind i OOXML med en møggreb i Geneve, og flere anvendelsesområder blev ikke helt gennemtænkt. Eksempelvis er ISO-datoer (ISO/IEC 8601) en kæmpe og kompleks specifikation, og ALT i den kan bruges som dato-angivelser i regneark. ISO-datoer skal også angives som UTC-datoer i OOXML og ikke lokal tid, og disse er blandt de ting, som de to herrer har kigget på opstraming af. Eksempelvis kunne det være en god idé at indsnævre værdimængden af tilladte datoer fra ISO 8601 som man fx gør det i XML Schemas, og det kunne måske give mening at tidsangivelser var i lokal tid i stedet for i UTC-tid. De gav en præsentation på mødet, og jeg forventer, at den bliver gjort tilgængelig snarest muligt.

... og hvad så med mig? Jo, jeg går lidt og sysler med en tilføjelse til OOXML, som den virkeligt mangler - ikke mindst i forhold ti ODF - nemlig kryptering. Denne "feature" er ikke beskrevet i OOXML, så det er i mine øjne på høje tid, at det sker. Regn med at se noget konkret i løbet af foråret.

![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")