Ecma brengt verbeteringen aan in Office Open XML

De leden van TC45 van de Ecma hebben opnieuw een aantal verbeteringen aangebracht in de ooxml-specificatie. Inmiddels is iets meer dan de helft van de door de nationale standaardisatiecomités ingebrachte commentaren verwerkt.

Zo heeft de werkgroep besloten dat datums vanaf nu niet alleen als getal mogen worden opgeslagen, wat de snelheid van berekeningen ten goede komt, maar ook als waarde zoals gespecificeerd in de ISO-8601-standaard. Verder bevatte het ooxml-voorstel geen mogelijkheid om weken op een andere dag dan de zondag of de maandag te laten beginnen, en ook die omissie is nu weggewerkt. Zowel de eerste dag van de week als het weekend kan nu gespecificeerd worden.

De Ecma stelt daarnaast voor om de manier waarop de taal van documentdelen wordt opgeslagen te veranderen. Hiervoor werd namelijk gebruikgemaakt van een door Microsoft ontwikkelde koppeltabel, maar dat wordt nu veranderd in een manier die is vastgelegd in IETF BCP 47. Verder meent de werkgroep dat moet worden afgestapt van een lijst met vooraf gedefinieerde paginarandelementen en dat iedereen de mogelijkheid moet krijgen paginaranden toe te voegen.

Tot slot is besloten om de wijze waarop spreadsheetformules en tekstvelden worden opgeslagen aan te passen naar een internationaal geaccepteerde syntactische metataal, ISO/IEC 14977:1996. Deze aanpassing zou de implementatie en validatie van de specificatie eenvoudiger moeten maken.

In augustus is de uitslag gepubliceerd van de stemming over de vraag of de ooxml-specificatie versneld een Iso-standaard zou moeten worden. Door de meeste nationale standaardisatiecomités was niet alleen een stem uitgebracht, maar was ook een serie verbeterpunten aangedragen. In totaal waren dit er 3522 en daarvan is nu 51 procent verwerkt door technical committee 45 van de Ecma.

Reacties (64)

Mooi dat er aan doorgewerkt wordt, maar het toestaan van 2 formaten om een datum op te slaan is iets dat op mij niet echt handig overkomt. MS kennende zal in Redmond worden gekozen voor de opslag als getal, waarbij ze dan dus wel netjes aan de spec voldoen.

Volgens mij zou OOXML als formaat een stuk meer standaard zijn als er werd uitgegaan van bestaande (ISO) standaarden voor bepaalde onderdelen. Door toe te staan dat er zaken in het formaat terechtkomen omdat dat nu eenmaal zo in MS Office is geïmplementeerd is geen goede zaak, IMHO.

Mooi dat er aan doorgewerkt wordt, maar het toestaan van 2 formaten om een datum op te slaan is iets dat op mij niet echt handig overkomt. MS kennende zal in Redmond worden gekozen voor de opslag als getal, waarbij ze dan dus wel netjes aan de spec voldoen.

Dat is ook relatief gunstig want spreadsheet worden al 25 jaar lang gemaakt met decimale datums en daar is dus een ton aan kennis en broncode voor beschikbaar. Bovendien zijn spreadsheets juist erg handig en zeer snel met decimale waardes. Het is juist het ISO 8601 formaat dat problemen oplevert omdat het als string representatie van een datum bijvoorbeeld veel onhandiger rekent en sorteert. spreadsheet zullen dat dan ook vrijwel altijd intern converteren naar een decimaal rekenveld en bij het tonen op een scherm of bij saven in een file weer naar een ISO formaat terugconverteren. Een spreadsheet kan verder natuurlijk niks met een ISO datum.

[Reactie gewijzigd door 80466 op 12 december 2007 14:48]

Tegen dat intern converteren is toch ook helemaal niets op tegen? Het gaat er alleen om dat in de specificatie van het bestandsformaat één, éénduidige manier gebruikt wordt om een datum te noteren. Wat een programma intern doet is totaal niet interessant, dat is een implementatiedetail dat geen enkele invloed heeft op de implementeerbaarheid van de standaard of op de operabiliteit met andere software.
Dat je intern niet gaat sorteren op een stringrepersentatie is natuurlijk helder.

Dat is inderdaad precies waar het hier ook om gaat: implementatie vs open specificatie. Een van de argumenten die MS gebruikt is dat OpenOffice een oneerlijke voorsprong heeft mbt tot ODF, omdat ODF afgeleid zou zijn uit de implementatie van OpenOffice. Door in de specificatie van OOXML zaken op te nemen die toevallig goed aansluiten bij de implementatie die al in MS Office zit doet MS natuurlijk precies hetzelfde.

MS doet heftige pogingen om het implementeren van OOXML zo goedkoop mogelijk te houden voor MS door zoveel mogelijk de implementatie in Office 1 op 1 over te namen in de standaard.

Het grappige aan dat geklooi met datum formaten is trouwens dat dat voor een deel terug te voeren is op de manier waarop Lotus 1-2-3 ooit omging met datums. MS heeft destijds de beperkingen van 1-2-3 gewoon overgenomen en eigenlijk nog iets erger gemaakt. Het gaat dus om 'functionaliteit' die nu al een jaar of 25 oud is.

Tegen dat intern converteren is toch ook helemaal niets op tegen?

Let wel dat je in een spreadsheet makkelijk tientallen miljoenen datums kan opslaan.
Bij het inlezen die allen converteren is bepaald niet snel.
Ook is een ISO datums niet altijd op een identieke wijze opgebouwd.
Qua performance zijn decimale datums daarom veel sneller. Ook nemen ISO datums meer ruimte in en zijn als string daarom langzamer te parsen en gebruiken meer memory voor een XML parser die een bestand bij het inlezen valideert.

En spreadsheets van meerdere GB aan data met tientallen miljoenen datums zijn met Office 2007 tegenwoordig zo gemaakt.

Aan de andere kant hebben decimale datums in theorie oneindige nauwkeurigheid.
Waar decimale datums vooral slecht in zijn is tijdzones.
Echter wat je ook niet graag wilt in een spreadsheet is gemengd tijdzone datumtijdvelden en bijvoorbeeld Excel ondersteunt dat dus ook niet.

Het is ook niet geheel duidelijk hoe de office formaten tijdzones ondersteunen. De ODF specificatie laat formeel gezien tijdzones toe maar zover ik weet gebruikt geen enkele spreadsheet die en is het onzeker hoe huidige spreadsheets ze behandelen als ze in een ODF document voorkomen.

[Reactie gewijzigd door 80466 op 12 december 2007 17:03]

Een spreadsheet met tientallen miljoenen datums... Misschien ben ik ouderwets, maar ik zou daarvoor een database oplossing verwachten? Dus een serieuze vraag; wat voor toepassing moet ik dan aan denken?

Een selectie uit een database bijvoorbeeld

Hoe bedoel je? Eén van de belangrijke redenen om gebruik te maken van de ISO8601 notatie is juist dat het zo makkelijk rekent en sorteert.

20031108 is eerder dan 20031202 en 20050130 etc., heel simpel te sorteren...

Rekent dit makkelijk?

Wat is het aantal dagen tussen 20041205 en 20070812?

Of in excel:
2004-12-05=38326,00 (in excel)
2008-08-12=39306,00 (in excel)

@maurits, jvdmeer en kidde. Er is blijkbaar een misvatting over ISO8601 datums en de subset daarvan die deze documenten gaan gebruiken.

Voorbeeldje uitgaande 12-12-2007 (is trouwens NEN-standaard voor nederlandse datumrepresentatie en niet ondersteund door ODF of OOXML)

Represetatie als:
ISO 8601 datum
"2007-12-12" of
"2007-12-12 00:00" of
"2007-12-12 00:00:00"
"20071212" of
"2007-12-12T00:00Z"
"2007-12-12T00:00:00Z"
"2007-12-12T00:00+00:00"
"2007-12-12T00:00:00+00:00"
"20071212+0000"
en er zijn nog veel meer varianten.
Dat is bepaald lastig. Daarom gebruiken deze office formaten de subset gekozen voor de W3C subset gebruikt in de XML standaard http://www.w3.org/TR/NOTE-datetime.
Let op, de door jou zo handig gevonden rekenformaat YYYYMMDD variant zit daar dus niet in en wordt dus ook niet ondersteund in Office formaten !!!!

Decimale datum
39428 of
39428,000000000

p.s. Dat een spreadsheet een datum misschien op een andere manier toont op het scherm heeft er natuurlijk niks mee te maken. Dat is geen formaat kwestie maar een spreadsheetimplementatiekwestie. Zo ondersteunt bijvoorbeeld excel wel het nederlandse datumformaat op je scherm maar slaat dat natuurlijk niet in een document zo op.

[Reactie gewijzigd door 80466 op 12 december 2007 16:38]

Wat is het aantal dagen tussen 20041205 en 20070812

Daarvoor hoort een functie (dbd-functie zoals die zelfgs op een grafische rekenmachine zit!)in de toepassing te zitten, NIET in de standaard.

ODF en OOXML zijn dan ook data opslag formaten en geen interne werk formaten. Dus ja, het ligt voor de hand dat het na inlezen intern anders wordt gerepresenteerd. Dus die 25 jaar ervaring mag je gewoon blijven gebruiken nadat je het ingelezen hebt.

Daarom zijn twee (of meer) formaten voor opslag niet nodig en dus ook onnodig complicerend en onhandig.

Dat is wel apart opgemerkt want juist decimale datum zijn dan natuurlijk veel efficienter voor opslag dan ISO datums.
Nog beter zijn dan bijvoorbeeld 64 bits binaire datums.

ISO datums zijn juist goed voor visuele representatie en ondersteuning van tijdzones en hebben in data opslag formaten veel minder nut.

[Reactie gewijzigd door 80466 op 12 december 2007 16:56]

Volgens mij is het veel beter om compleet te zijn en dus inderdaad tijdzones te ondersteunen. Je zegt het notabene zelf.

Mij lijkt een implicite waarde van een veld (een decimaal om rekenen naar een datum, met een impliciete begindatum en conversie algoritme) minder helder voor opslag dan een expliciete specificatie die helaas wat complexer is, maar wel duidelijker en niet ambigu. Deze datum, deze tijd in deze tijdzone.

Jij zegt dat maar dat is niet een slimme opmerking want hoewel het in theorie wel in ODF zit is er geen spreadsheet die het ondersteunt.
Als je het dus wel slim vind om compleet te zijn moet je toch even langs lopen bij alle spreadsheetbouwers in de wereld en hen vragen waarom zij het niet zo slim vinden

Gelukkig ben jij zo slim om te weten wat spreadsheets over een paar jaar wel of niet kunnen en willen ondersteunen. Dat ODF het ondersteund wil toch zeggen dat een aantal "slimme" mensen er voordeel in zien.

Daarbij is het misschien "slim" om een datum voor een spreadsheet niet anders op te slaan dan bijvoorbeeld een tekst-document binnen één bestandsformaat. Scheelt misschien een paar duizend pagina's specificatie en veel potentiële implementatie fouten als je modules hergebruikt. Dat zou ik nu slim vinden.

Dat ligt er maar aan wat je wilt.
OOXML gebruikt overal al gewoon datums in het ISO datum tijd formaat maar juist in spreadsheets is dus origineel gekozen voor een decimale datum omdat juist in een spreadsheet waar grote hoeveel heden data worden verwerkt ook de performance in de afweging een rol speelt.
In ODF zijn sowieso geen overwegingen opgenomen mbt tot performance.
In OOXML zijn dergelijke overwegingen wel opgenomen.
Dit levert als evidente uitkomst dat als je een OOXML implementatie hebt dat deze potentieel behoorlijk sneller kan zijn en minder gehuegen gebruiken dan een zelfde ODF implementatie en zeker op het gebied van (zeer) grote spreadsheets maakt dat wel een verschil.

@hAl

Dat (als getal opslaan) is ook relatief gunstig want spreadsheet worden al 25 jaar lang gemaakt met decimale datums en daar is dus een ton aan kennis en broncode voor beschikbaar.

Bovendien zijn spreadsheets juist erg handig en zeer snel met decimale waardes. Het is juist het ISO 8601 formaat dat problemen oplevert omdat het als string representatie van een datum bijvoorbeeld veel onhandiger rekent en sorteert.

Er is 1 verschil wat jij niet schijnt te begrijpen:
- de interne representatie: welke waarde staat in het geheugen zodat je snel kan rekenen
- de externe opslag: welke notatie wordt in het bestand gebruikt om het uitwisselbaar te maken met andere applicaties.

De hele marketing van OOXML is gericht op het feit dat het laatste mogelijk is. Overheden eisen immers uitwisselbare formaten.

OOXML zit vol met de interne rekenwaardes van 1 specifieke applicatie. Om een formaat te maken wat uitwisselbaar is hoort die applicatie dat interne rekenformaat om te zetten naar een standaard notatie zoals ISO 8601. Applicaties kunnen daarmee daarmee rekenen, en bij het inladen eventueel intern omzetten naar een interne rekenwaarde die handiger/sneller werkt.

Zo'n aanpak maakt velden als "datum vanaf 1904 voor excel bug" onnodig. Waarom moet iedere applicatie zich aanpassen aan een Excel bug? Excel had ook de interne datum als correcte ISO 8601 waarde kunnen opslaan, en die weer kunnen uitlezen, daarna intern kunnen omzetten naar zijn rekenwaarde. De rest van de wereld moet zich nu aanpassen aan het interne data model wat Excel gebruikt, in combinatie met alle bugs die Excel daarop heeft.

Deze aanpak is mogelijk ook de oorzaak van alle inconsequenties bij afstandsmaten, percentages (zoals "50%" vs "0.5" vs "perc50"), hexadecimale notaties of kleurcodes. Het zijn stuk voor stuk interne waarden die in dat specifieke deel van Office gebruikt worden, en nergens omgezet worden om het makkelijk uitleesbaar/uitwisselbaar te maken.

Het argument dat de software beschikbaar is gaat niet op. Er is juist genoeg software beschikbaar om te rekenen met ISO 6801 datums, aangezien die standaard al lang bestaat. Nu wijkt Microsoft's OfficeOpenXML hier van af, en moet iedereen die niet dezelfde algoritmes gebruikt als Microsoft zijn software aanpassen. Dat is niet allen tegenstrijdig met het idee dat het formaat goed uitwisselbaar is, maar ook nog eens erg buggevoelig.

[Reactie gewijzigd door YaPP op 12 december 2007 17:09]

- de externe opslag: welke notatie wordt in het bestand gebruikt om het uitwisselbaar te maken met andere applicaties.

Spreadsheets wisselen al 25 jaar lang decimale datums uit dus dat decimale datums voldoende interoperabel zijn leidt geen twijfel.

Het decimale ANSI_1600 formaat bijvoorbeeld is al een hele oude decimale datum standaard.

OOXML zit vol met de interne rekenwaardes van 1 specifieke applicatie

Behalve dan dat decimale datums juist door ALLE bestaande spreadsheets gebruikt worden en ISO datum dus niet.
ISO datum zijn dus juist meer specifiek en wel voor ODF spreadsheets implementies. Maar OOo of Gnumeric kunnen ook prima met decimale datums overweg. En hoewel de ODF specificatie ISO datums voorschrijven kunnen niet al deze applicaties al goed met alle ISO datum varianten uit de voeten.

Is dat niet grotendeels waar het hele OOXML v ODF argument om draait...?

Verder bevatte het ooxml-voorstel geen mogelijkheid om weken op een andere dag dan de zondag of de maandag te laten beginnen, en ook die omissie is nu weggewerkt. Zowel de eerste dag van de week als het weekend kan nu gespecificeerd worden.

Goede zaak, het was natuurlijk absurd dat MS maar even bepaalde dat de rest van de wereld op hetzelfde moment weekend moet hebben als de VS en Europa. Veel van mijn klanten hebben vrijdag en zaterdag als weekend en sommigen zelfs donderdag en vrijdag. Voor hen was dit een belemmering.

Week != Werkweek. Wel makkelijk natuurlijk, maar ik vraag me af waar dit voor is. Ik ken de andere kalender's ook niet van bv in de arabische wereld en hoe die inelkaar steken. Voor normaal westers gebruik zou het makkelijk zijn om in te stellen wat de werkdagen en vrije dagen zijn. De weeknummering veranderd namelijk niet omdat Jantje op een ander moment weekend heeft. Ik zie eerder problemen voorkomen omdat Jan zijn kalender door de wijziging week 2 aangeeft ipv 1 en dus de hele planning in de war kan schoppen.

Pas wanneer het incompatible zou worden met andere kalenders zie ik het nut.

Weeknummers worden bepaald in ISO8601 en zijn niet afhankelijk van wanneer het weekend is. Uit mijn hoofd zeg ik dat de eerste donderdag van het jaar bepaald wat week 1 is.

Een probleem waar dit duidelijk werd is bijvoorbeeld bij de spreadsheetfunctie NETWORKDAYS die het aantal werkdagen tussen twee data uitrekent. Die ging dus de mist in in alle landen waar het weekend niet op zaterdag en zondag valt.

Het is niet meer dan logisch dat dit is aangepast. Zaterdag en zondag als weekend waren 'hard gecodeerd' in het formaat, niet handig als miljoenen mensen en alle bedrijven om je heen vrijdag en zaterdag als weekend hebben.

[Reactie gewijzigd door Maurits van Baerle op 12 december 2007 12:25]

De eerste week met 4 of meer dagen in januari is week 1. Andere notaties die op hetzelfde neerkomen zijn:

quote: http://en.wikipedia.org/wiki/ISO_8601#Week_dates

Mutually equivalent definitions for week 01 are:
the week with the year's first Thursday in it
the week with 4 January in it
the first week with the majority (four or more) of its days in the starting year
the week starting with the Monday in the period 29 December - 4 January
If 1 January is on a Monday, Tuesday, Wednesday or Thursday, it is in week 01. If 1 January is on a Friday, Saturday or Sunday, it is in week 52 or 53 of the previous year.

In die definitie is het dan wel van belang om te bepalen wat de eerste dag van de week is natuurlijk. Anders kan je ook niet bepalen of er vier dagen in die week zitten.

Er zijn wereldwijd verschillende definities wat week 1 is. Zo zijn de chinezen er niet van overtuigd dat het jaar op 1 januari begint.

Daarnaast zijn er enkel in windows al 3 procedures om week 1 te definieren. Volgens de SDK

0 Week containing January 1 is the first week of the year
1 First full week following January 1 is the first week of the year
2 First week containing at least four days is the first week of the year

Dus zo simpel is het allemaal niet.

Geen wonder dat zo'n standaard op een moment 6000 pagina's wordt met dit soort details.
Hoe zit het eigenlijk met al deze punten in ODF?

Geen wonder dat zo'n standaard op een moment 6000 pagina's wordt met dit soort details

Hoezo? die redernatie snap ik niet...
De standaard was al 6000 pagina's voordat er commentaar binnen kwam.

Hoe zit het eigenlijk met al deze punten in ODF?

ODF bestaat uit 700 pagina's.

Dit kan doordat in tegenstelling tot OfficeOpenXML doordat bij ODF:

- bestaande standaarden herbruikt worden.
Je kunt je MathML en SVG code / dll's dus direct herbruiken.

- opmaak centraal geregeld is.
Voor alle objecten, velden (kopteksten, voetteksten, celstijlen, etc..) worden dezelfde stijlen herbruikt. Zelfs tussen de verschillende applicaties (tekstverwerker, presentatie) worden dezelfde tags voor stijldefinities herbruikt.
@hAl: natuurlijk gebruikt OOXML stijlen.. maar voor "excel" is die weer anders, en voor "powerpoint" ook weer. en voor (ik meen) vootnotes ook weer anders. Er wordt te weinig herbruikt.

- afhandeling van eenheiden is ook eenmalig gedefineerd.
Niet dan "50%", of weer "50.00" of "0.5" of "pct15" of voor dezelfde waarde. Dat geld ook voor kleuren, die soms weer op naam staan, dan weer op kleurcode, hexcode of RGB code.

[Reactie gewijzigd door YaPP op 12 december 2007 16:30]

Je kunt je MathML en SVG code / dll's dus direct herbruiken.

Je kunt SVG code modules zoals dll niet hergebruiken voor ODF.
ODF ondersteunt namelijk geen SVG maar ondersteunt een deel van de SVG tag/features aangevuld met openoffice 3D tags maar dan wel allemaal in een openoffice namespace.
ODF is dus ook niet compatible met SVG.

Wat je wel kan doen is eventueel broncode uit een SVG ondersteuniong hergebruiken om de tags/features ondersteuning te dupliceren. Maar bijvoorbeeld schemavaliderende W3C-SVG hoeft niet te valideren in ODF-SVG.

Dit kan doordat in tegenstelling tot OfficeOpenXML doordat bij ODF:
opmaak centraal geregeld is

Het is misschien beter geen onzin uit te kremen als je niet weet hoe OOXML werkt.
OOXML gebruikt natuurlijk ook gewoon stijlen.
Je kunt zelfs in een OOXML bestand de stijlen als die in aparte XML deelbestanden staan gewoon vervangen en zo in 1 keer de complete stijl van je document aanpassen zoals je dat in een webpagina met CSS zou doen.
Dat hier mensen zo maar gaan zitten beweren dat dit niet zo is geeft het hele niveau van de discussie door tegenstanders van OOXML wel weer heel goed aan.

[Reactie gewijzigd door 80466 op 12 december 2007 14:23]

Volgens mij snap je niet wat Yapp bedoelt...
Zoals ik het lees bedoelt hij dat zowel spreadsheets als tekstverwerkers als opmaak documenten dezelfde tags gebruiken. Het grote voordeel is dat je een simpelere en dus bruikbaardere definitie hebt.

Dat je met OOXML ook stijlen kunt wisselen door stylsheets is zoals ik jouw tegenargument lees is geen argument hiertegen. Het gaat om overzichtelijkere stijlsheets, en niet dat er uberhaubt stijlsheets zijn.

Althands, dit is wat ik begrijp uit hAl en Yapp's stukjes.

[Reactie gewijzigd door curumir op 12 december 2007 18:07]

Dat hier mensen zo maar gaan zitten beweren dat dit niet zo is geeft het hele niveau van de discussie door tegenstanders van OOXML wel weer heel goed aan.

Gelukkig voor de voorstanders wordt de discussie binnen standaardorganen gevoerd door Microsoft certified-gold partners - en verenigingen van Microsoft certified-gold partners (waarvan enkele ook in de NEN vertegenwoordigd zijn om hun eigen maar dus ook Microsofts belangen uit te dragen), dus er is geen reden je zo druk te maken.

[Reactie gewijzigd door kidde op 12 december 2007 15:52]

Zoals ook de concurrenten van Microsoft en leden van de OpenDoc society zijn vertegenwoordigt in het NEN committee bedoel.

Hoezo? die redernatie snap ik niet...

Ik had er nooit bij stilgestaan dat ook definities als "wat is het weekend" in zo'n specificatie zouden staan. Als zaken tot op dusdanig detail gedefinieerd worden, verbaast het me niet dat een specificatie zo groot kan worden. Simpele redenatie toch eigenlijk?

ODF bestaat uit 700 pagina's.

Dat bedoelde ik niet, ik bedoel, hoe zit het met datumnotatie, definities van het weekend, enzovoort bij ODF. Dus de punten waarop OOXML wordt aangepast volgens dit artikel.

ODF gebruikt de genoemde ISO datum standaard zover ik weet.

En als je je verbaasd over de grote van de OOXML spec is toch juist het verschil met ODF, dat het blijkbaar met 10% van de pagina's kan, erg schrijnend.

[Reactie gewijzigd door curumir op 12 december 2007 18:08]

Ik zeg juist dat het me op deze manier niet verbaast... Waarom moet iedere discussie over een van de twee formaten meteen ondergesneeuwd worden door haastige paniekreacties? Tjongejonge.

Je zei dat het je niet verbaast als er zo'n uitgebreide definities in staan. Daar had je echter eerst niet bij stil gestaan schreef je, dus heeft het je daarvoor wel verbaasd?
En het zou je nog steeds moeten verbazen omdat hetzelfde detailniveau ook in ODF te vinden is, in +/- 700 vs +/- 6000 pagina's.

Het heeft dus helemaal niks te maken met paniek dat ik het raar vindt dat de specs van één formaat bijna 9x zo groot is als het andere, terwijl ruwweg dezelfde functionaliteit afgedekt wordt.

Het detail niveau in de ODF specificatie is enorm veel lager.
De ODF specificatie is veel meer een syntax beschrijving. Er zijn talloze voorbeelden van stukken ODF die je niet kunt implementeren zonder bijvoorbeeld te kijken in de openoffice broncode omdat in de specificatie absoluut niet staat wat het betekent.

Ik zal even een voorbeeldje geven van het diepte niveau van de ODF spec:

15.5.32 Text Autospace
Use the style:text-autospace property to specify whether to add space between Asian,
western, and complex text.
The possible values are none and ideograph-alpha.
en dan nog aangevuld met de XML schema definitie.

Nou mag jij raden
A) wat text-autospace precies doet want de uitleg is nogal kort
wat de value none betekent
C) wat de value ideograph-alha betekent

Let wel dit is alles wat erover in de ODF sepc staat.
Je kunt dit natuurlijk niet implementeren puur op basis van deze spec.
Gelukkig kun je de OpenOffice broncode inzien om te kijken wat het zou moeten doen (p.s. is de opendocument broncode meer of minder dan 6000 pagina's ?)

[Reactie gewijzigd door 80466 op 12 december 2007 20:36]

Dit is dus gelijk het probleem van de ODF standaard. Er zijn een hoop zaken die niet duidelijk gedefinieerd zijn en derhalve dus meerdere - incompatible - implementaties mogelijk maken. OpenOffice is geen standaard, dit is een implementatie. Kijken naar de OO source heeft dan ook niet zoveel nut, want ten eerste is het een aanname dat OO de standaard goed volgt (wel waarschijnlijk, duh, maar het blijft een aanname) en ten tweede horen dit soort zaken in de standaard gedefinieerd te worden.

Een standaard hoort zo te zijn, dat 10 verschillende ontwikkelaars onafhankelijk van elkaar 10 verschillende implementaties kunnen maken die alle 10 volledig compatible met elkaar zijn. Op dit moment kan dit met ODF niet, omdat er teveel ruimte wordt open gelaten. Een van de dingen die bij OOXML zijn/worden geprobeerd is juist deze ruimte niet te geven, zodat elke implementatie compatible is met een andere.

ODF refereert op deze gebieden naar bestaande ISO standaarden, en probeert niet alles te 'her'definieren. Hierdoor is de standaard beter compatible met bestaande standaarden en ook op zichzelf een kleiner document.

Dat is niet juist.
ODF refereert nauwelijk naar ISO standaarden. ODF refereert naar slechts 3 stuks ISO standaarden waaronder Unicode en iso8601) en negeert de overige ISO standaarden grotendeels en spreekt ze soms zelfs tegen.

ODF refereert verder vooral naar een aantal webstandaarden en IETF rfc's maar bijvoorbeeld niet naar de IETF BCP 47 taallijst die nu in OOXML gebruikt zal gaan worden.

OOXML refereert juist iets meer naar ISO standaarden en veel minder naar webstandaarden.

ODF refereert nauwelijk naar ISO standaarden. ODF refereert naar slechts 3 stuks ISO standaarden waaronder Unicode en iso8601) en negeert de overige ISO standaarden grotendeels en spreekt ze soms zelfs tegen.

Dat is interessant. Heb je hier voorbeelden van? Want ik zie dit vaak terugkomen in de (helaas grotendeels op emoties gebaseerde) ODF/OOXML discussie.

ODF refereerd vooral naar W3C standaarden (XLink en SVG bijvoorbeld), heel erg verwonderlijk is dat niet hoor.

XML is namelijk een ontwikkeling van het W3C en deze organisatie heeft hierop weer diverse standaarden beschreven, zoals het hierboven genoemde XLink en SVG.

Microsoft daarentegen maakt nauwelijks gebruik van deze XML-standaarden en overtreed her en der de regels die voor XML vastgelegd zijn.

Zo is OpenXML niet erg human-readable, terwijl dit wel "voorgeschreven" is in de XML standaard.

Dat is interessant. Heb je hier voorbeelden van?

Die vraag _is_ al beantwoord, hAl geeft boven jouw reactie al aan dat ODF naar ISO 8601 refereert.

@MariavonTrapp: Sorry, misverstandje...

[Reactie gewijzigd door kidde op 12 december 2007 16:10]

Nee, dat is hij niet. Ik wil weten waar ODF de ISO standaarden tegenspreekt.

De term tegenspreken is daarin nogal gevoelig.
Misschien had ik die niet moeten gebruiken.
Het betreft veealeer afwijkende methoden.
Bovendien is het niet alleen ODF maar ook OOXML op allerlei plaatsen afwijkt van ISO standaarden.

Zo heeft ISO een eigen vector graphics formaat en een eigen math formaat en een eigen standaards om naar documeten te verwijzen en een eigen metadata formaat. Dergelijke zaken worden door beide standaarden vervangen door niet ISO formaten.

Het is in die zin ook wel grappig als voorstanders van ODF beweren dat er voor documenten maar 1 standaard kan zijn terwijl er dus al voor ODF allerlei ISO document standaarden waren en die door ODF allemaal consequent genegeerd zijn.

Het is in ieder geval dus niet zo dat ODF zich beter aan de ISO standaarden houdt of deze ISO standaarden hergebruikt wat gesuggereerd werd door de reactie waar ik origineel op reageerde.

Je geeft alleen aan waar zowel ODF als OOXML ISO negeren. Nog steeds geen onderbouwing van je eerdere argument.

En daarbij, zoals de kleine pinguïn al aangeeft, gebruikt ODF bij b.v. Vector graphics en Math andere geaccepteerde standaarden (W3C). Valt natuurlijk over te twisten, maar het is in ieder geval een geaccepteerde standaard bij een extern standaarden orgaan.

Wat betreft één standaard; natuurlijk zijn er oude standaarden die verbeterd en uitgebreid moeten worden, maar de vraag gaat er om waarom er een vrijwel identieke standaard, op hetzelfde moment moet komen. En dan nog met veel haast en politiek gekonkel, nadat net de eerste goed was gekeurd.

Ik denk dat iedereen wel weet waarom Microsoft zo'n haast heeft...

Ik ben toch wel benieuwd: kunnen nu door de introductie van het ooxml Microsoft Office en OpenOffice elkaars documenten openen zonder dat er vormfouten optreden?

Je kunt het denk ik het beste vergelijken met webbrowsers; webbrowers hebben elk hun eigen render implementatie, aan de hand van een gestelde (x)html standaard. Hoewel hier dus duidelijke standaarden voor zijn, zie je dat een en ander regelmatig verschilt tussen bijvoorbeeld Safari (KTHML), Firefox (Mozilla) en IE. Nu kan hierbij de kanttekening geplaatst worden dat IE vrij weinig echt correct volgens standaard implementeert, maar de vraag is natuurlijk ook in hoeverre dat straks in MS Office gaat gebeuren. Kortom: waarschijnlijk wordt het allemaal vrij interchangable, maar voor 100% compatibiliteit is het maar afwachten hoe goed de developers hun werk doen.

maar voor 100% compatibiliteit is het maar afwachten hoe goed de developers hun werk doen.

En belangrijker nog: of de OOXML specificatie wel eenduidig genoeg is. Als delen van de OOXML specificatie op verschillende manieren te interpreteren zijn, zal dat waarschijnlijk ook door ontwikkelaars worden gedaan.

(Geen idee hoe goed/slecht OOXML wat dat betreft is)

metaal.. maakt een hele wijze opmerking.. is de OOMXL specificatie wel eenduidig.. Wat dat is 1 van de problemen in (x)html Lees de design documents er maar eens op na en je kunt gaat discusieren over het feit of ze bedoeld hebben of het border nu wel of geen onderdeel uitmaakt van je box.

Ja Microsoft heeft veel vieze dingen gedaan in IE , met name in IE 6 , maar ondanks dat ik toch wel een Apple fanboy ben.. het ligt het helemaal aan Microsoft.. W3C heeft ook schuld

Dat ligt aan twee factoren: ten eerste of de definitie van hoe een bepaald element er visueel uit hoort te zien goed gedefinieerd is, en ten tweede hoeveel tijd (== geld) de bedrijven / mensen die programma's die OOXML programma's maken erin willen investeren.

Goed dat er gewerkt wordt aan de verbeteringen.

Ik vraag me nu alleen concreet af of Microsoft deze wijzigingen ook gaat ondersteunen. Momenteel komt de OfficeOpenXML specificatie niet overeen met hetgeen dat Office 2007 produceerd. Als dat nog verder uitwijkt hebben we dus een standaard die de openheid van ODF probeert na te streven, maar verder in geen enkele software echt geimplementeerd is.

[Reactie gewijzigd door YaPP op 12 december 2007 12:02]

Ik denk dat ze wachten met een implementatie totdat alle wijzigingen verwerkt zijn en de standaard is aangenomen. Anders ben je iedere week Office aan het updaten.

Goed dat er gewerkt wordt aan de verbeteringen.

Zeker, maar het tempo stemt nog niet tot optimisme: Als 51% van de 3522 commentaren opgelost zijn, zijn er nog 1726 commentaren die moeten worden opgelost voor de stemming in feb 08. De standaardorganen moeten dus de oplossingen van die 1726 commentaren die er nu nog niet zijn, beoordelen vòòr feb 08, nog afgezien van dat ze moeten checken of e verwerkte 1700+ commentaren afdoende zijn behandeld. Duidelijk is dat dit menselijkerwijs een bijna onmogelijke opgave is als je de kwaliteit wil waarborgen.

Als die 49% van de commentaren die nog niet zijn opgelost van 5% van de stemmers komt hoeven ze die helemaal niet op te lossen.

Simpel voorbeeld:

Er zijn 3 stemmers bij de eerste stemming, A is voor, B tegen met 1 commentaar, C tegen met 9 commentaren. Voorstel afgewezen

MS lost het commentaar van B op, (10% van alle commentaren)

Bij de volgende stemming zijn A en B voor, C tegen met 9 commentaren. Voorstel aangenomen.

Tja in plaats van geld uit te geven om ooxml te ontwikkelen en mensen om te kopen voor te stemmen kan Microsoft ook een odt implementatie maken. Nu krijgen wij zo 2 standaarden.

Welke is dan standaard?

Tja in plaats van geld uit te geven om ooxml te ontwikkelen en mensen om te kopen voor te stemmen kan Microsoft ook een odt implementatie maken. Nu krijgen wij zo 2 standaarden.

Welke is dan standaard?

Je begrijpt natuurlijk wel dat Microsoft er baad bij heeft dat ODF geen succes word aangezien een goed ondersteund uitwisselformaat betekend dat je Office zo kunt vervangen door iets anders.

Overheden hebben ook door dat ze vastzitten aan Office doordat hun informatie in een gesloten formaat opgeslagen is, en er nooit concurrentie kan ontstaan die dat gesloten formaat evengoed kan ondersteunen als Microsoft zelf. Daarom eist de overheid tegenwoordig open formaten, zodat iedere leverancier een gelijke kans heeft.

Om niet de boot te missen doet Microsoft nu een hoop moeite om OOXML over te laten komen als "open". De naam lijkt zelfs verwarrend veel op OpenOffice.org XML, waarop OpenDocument gebaseerd is. In werkelijkheid is OOXML helemaal niet makkelijk te implementeren door concurrenten. Met een ISO stempel erop wordt het nog moeilijker managers te overtuigen van dit feit. In de praktijk zullen we dus geen stap verder zijn als iedereen overgaat op OOXML. Microsoft is wel de grote winnaar, zij zullen het komende decenium weer gebakken zitten.

aangezien een goed ondersteund uitwisselformaat betekend dat je Office zo kunt vervangen door iets anders.

Een dwaas idee.
Je kiest een office applicatie vanwege de features, niet vanwege het onderliggende formaat.

Het onderliggende formaat is naar mijn inzien een feature van de suite. De enige reden waarom ik Ms office ipv open office gebruik is dat mijn werk vaak naar andere gebruikers moet welke alleen MS office gebruiken en de open bestanden daar vervormd worden weer gegeven.

Daarbij maakt het toch weinig uit of het formaat interoperable is.
Dat ligt voornamelijk aan de kwaliteit van de implemntatie
De interoprabiliteit van deze beide Office formaten ligt voornamelijk in de beschrijving van de syntax en de data. De kans dat de twee bestanden er hetzelfde uit zullen zien is gering op basis van de standaarden.
Zeker bij de ODF standaard waar vrijwel niets beschreven staat over hoe een document er uit zou moeten zien.
Wil je daar interoperabiliteit in hoe documenten eruit moeten zien dan kan dat alleen door bij het ontwikkelen rekening te houden met de eigenschappen van die applicaties naast de formaat specificatie.

Zo kan bijvoorbeeld iedereen de specificatie van de huidige office files opvragen en implementeren maar je kunt alleen in MS Office zien hoe het eruit zou moeten zien. Dus OpenOffice beschikt zonder twijwel over de vollidgie specificatie van die files maar dat betekent nog niet dat de files qua uiterlijk volledig interoperable zijn. Bijvoorbeeld omdat ze bepaalde features van MS Office gewoon niet ondersteunen.

In werkelijkheid is OOXML helemaal niet makkelijk te implementeren door concurrenten.

Hoe kom je bij deze onzin? De OOXML standaard is volledig open ne beschrijft exact wat je wel en niet mag doen, itt de ODF standaard.

Het enigste wat niet beschreven staat is hoe om te gaan met de oude propriety Office documenten voor backward compatibility met oude Office versies. Dit is ten eerste niet iets wat iemand hinderd om een nieuwe implementatie te maken en ten tweede niet onlogisch aangezien die oude formaten closed zijn. De reden voor een standaard document formaat is ook om documenten in dat formaat uit te kunnen wisselen, niet om oude documenten in format x om te kunnen zetten in formaat y.

Als iemand een kantoor applicatie schrijft met de OOXML standaard zal deze volledig compatible zijn met MS Office 2007 (of een andere implementatie). Hij zal alleen niet noodzakelerwijs (aan de hand van de OOXML standaard) in staat zijn om een .doc van Office XP correct te lezen en weer te geven. Dat dit geen probleem hoeft te zijn, laten de verschillende pakketten als OOo zien.

Het zou wel fijn zijn als je met argumenten kwam in plaats van stellingen. Iets heel vaak heel hard roepen maakt het nog niet waar.

Zonder verder op de details in te gaan (want die ken ik natuurlijk niet, net zoals de meerderheid van de reacties hier meer vanuit de onderbuik dan vanuit het verstand is): zou een standaard die in meer dan 6000 pagina's beschreven wordt nu 'gemakkelijk' te implementeren zijn?

Als iemand een kantoorapplicatie schrijft die compatible is met het OOXML formaat (formaat, want het is nog geen ISO standaard) heeft niet per definitie iets wat volledig compatible is met MSO. Er is alleen de mogelijkheid dat de data wordt gelezen en geschreven. De features van het pakket kunnen nog altijd behoorlijk verschillen. Wel of geen Clippy bijvoorbeeld, om maar een favoriet te noemen.

Deze formaten ondersteunen een complete office suite.
Elke veronderstelling dat je een complete office suite makkelijk kunt implemnteren zijn natuurlijk onzinnig.

Verder zijn deze formaten slechts de opslag van een document en in een office implementatie zit natuurlijk nog veel meer.