Versnelde keuring Open XML vindt doorgang

Nadat we in maart meldden dat Office Open XML in aanmerking kwam voor een versneld standaardisatieproces, heeft de Ecma nu bekendgemaakt dat ooxml uiterlijk binnen vijf maanden beoordeeld moet zijn.

De komende vijf maanden zullen de leden van de organisatie hun stem kunnen uitbrengen over de eventuele goedkeuring van de Office Open XML-specificaties als officiële iso-standaard,dat het ecma-label al eerder verleend werd. Als alles naar Microsofts wens gaat, dan kan het ooxml-formaat begin augustus iso-gestandaardiseerd zijn en daarmee een volwaardige concurrent van OpenDocument - dat in mei al tot standaard verheven werd - worden. Steeds meer overheden en instanties stellen de eis dat gebruikte bestandsformaten officieel goedgekeurd zijn als Ecma-standaard, maar dat volstaat niet altijd. Zo eist Californië bijvoorbeeld dat er meerdere implementaties van de standaard beschikbaar zijn zodat vrije keuze voor software gewaarborgd blijft. Novell heeft echter al ondersteuning voor ooxml in OpenOffice ingebouwd.

Reacties (61)

[Little Penguin]

Betekent dit dan ook dat bekende inconsistencies in de Office Open XML standaard er niet uitgehaald gaan worden?

Ik hoop van niet, want dat zal betekenen dat wij als ontwikkelaars over 5+ jaar lekker zullen gaan schelden op de bestaande verantwoordelijken (ECMA cs)

/me Penguin is van mening dat een standaard naar de toekomst moet werken, niet naar het verleden - zoals nu dus wel met OOXML gebeurt.
En om de reacties over compatibiliteit met huidige binaire office bestanden voor te zijn:
Als we nu al weten wat de fouten zijn kunnen we nu al specificeren hoe een applicatie de conversie moet doen tussen binair en XML...

Dat levert in de toekomst alleen maar voordelen op, omdat we bij het uitlezen van de XML niet na hoeven te denken in hoeverre een bepaald deel van de standaard met bekende[ fouten erin is ontworpen...

[Maurits van Baerle]

Het zegt nog niet zoveel over of ze er wel of niet uitgehaald zullen worden. Daar is het nog te vroeg voor. Het proces van goed- of afkeuren moet nog beginnen.

Nu kunnen eventuele bezwaren tegen goedkeuren op tafel komen en kunnen dus dit soort zaken besproken worden. Als een aantal leden alleen instemmen met goedkeuring als bepaalde MSOOXML-tekortkomingen worden opgelost is er een redelijke kans dat het MS dwingt de standaard te verbeteren.

[oliveroms]

wedden dat dit gewoon dr doorheen gedruikt word en dat er op mirakuleuze wijze nix(of nauwlijks) van tegenspraak gehoord word? Als je groote diepe portomonee hebt is dat heel makkelijk te realizeren. En mensen zijn altijd nog omkoopbaar.

[Little Penguin]

Daar ben ik dus zo bang voor, het er snel goedkeuren van de standaard.

Als er echter ondanks de fast-track nog aan de standaard gesleuteld kan gaan worden dan is dat een pluspunt. Waarbij ik hoop dat men alle -niet [goed] gedocumenteerde- verwijzingen naar oude applicaties cq inconsistenties vanwege oude apps zal verwijderen.

(Zoals bijvoorbeeld de datum-bug uit Lotus 1-2-3, die dus ook in O O XML zit...)

[Verwijderd]

Onbegrijpelijk dat bijvoorbeeld die datum-bug in het nieuwe XML formaat er weer gewoon in zit, dit had idd in conversieprogramma's naar het oude formaat moeten zitten, en alle overbodige binaire (weet iemand een beter woord voor zooi?) eruit...

[Verwijderd]

Er zit geen binaire zooi in OOXML.

Er zit wel wat base64 encoded elementen in maar dat is met name voor het toevoegen van digitale signatures. Dat zou ik echter niet als zooi omschrijven.

[YaPP]

Er zitten inderdaad geen binaire blobs in, maar wel binaire vlaggen. Voor het idee, vergelijk:

<img src="test.png" width="12" height="12" border="0">

en:

<img src="test.png" options="789504">

In beidde is dezelfde informatie opgeslagen. Alleen moet je bij optie 2 weten welke bits voor welke informatie staan. Zet 789504 maar om naar bits.

OOXML doet het laatste voor bepaalde informatie.

@hAl: probeer eens bitmasks met XSLT te verwerken...

[Verwijderd]

Volgens mij is dit geen echt voorbeeld omdat het het volgens mijn in OOXML niet zo werkt.
Er zijn echter inderdaad een paar opties in OOXML die worden aangeven via waardes die overeenkomen met bitmasks.
Dat verdient weliswaar niet echt een schoonheidsprijs maar is ook niet echt ingewikkeld.
Dat zou wel volgens mij wel iets zijn waarvan bijvoorbeeld Ecma kan aangeven deze opties te vervangen door andere meer betekenisvolle waardes tijdens het standaardisatieproces. (direct al of in een volgende 1.1 versie).

[Verwijderd]

@hAl: probeer eens bitmasks met XSLT te verwerken...

Validatie van bitmasks is gewoon mogelijk. Dat laat ik echter liever aan een erkende XML expert over:
http://www.grokdoc.net/in...icant_validation_problems

[Verwijderd]

(1) vergelijk niet de XML export van Word 2003 met OOXML, dat is namelijk mijlen apart.
(2) ECMA is een internationaal standaardisatie-orgaan en zoals Grokdoc al aangeeft is er meer dan genoeg dat dit orgaan kan doen om OOXML een echte standaard te maken.

En zodra de OS crowd in de echte wereld met legacy support komt horen we het wel. Beginnen vanaf 0 zonder rekening te houden met de bestaande userbase, dat is nou echt iets dat alleen OS kan...

[The Noid]

ECMA of ISO?
OOXML is toch al een ECMA standaard? Dus het gaat toch over de ISO standaardisering? Wat heeft de ECMA daar dan nog mee te maken?

[Dreamvoid]

Het was al ECMA goedgekeurd, en het is gebruikelijk dat er dan een versnelde ISO certificatie procedure volgt. Microsoft's concurrenten hebben dit proberen te dwarsbomen, maar dat is dus blijkbaar niet gelukt.

[kidde]

Dat het de concurrenten niet gelukt is de versnelde keuring tegen te houden, kan juist ook nadelig uitpakken voor Microsoft.
Immers, niet meer dan een kwart van de stemmende standardiesatie-organen (1 per land) mag tegen zijn, en meer dan 2/3 moet vóór zijn.
Aangezien er momenteel nogal wat landen wat bezwaren hebben, en een aantal blanco (dus niet vóór stemden) heeft Microsoft bij een versnelde keuring minder tijd om die landen te overtuigen.
Vooral het standaardenorgaan uit Kenia (huiswerk het beste gedaan, lof!) had zéér sterke argumenten waarom OpenXML als standaard niet deugde; oa
-OpenXML heeft, anders dan Microsoft beweerd, niets te maken met backwards compability, omdat de macro's uit oude office versies er niet in gespecificeerd zijn,
-OpenXML conflicteert met meerdere ISO standaarden (waaronder de eeuwenoude Gregoriaanse kalender, papierformaten en kleuren)
-OpenXML houdt zich niet aan algemeen aanvaarde XML-afspraken wat betreft leesbaarheid
-Variabele-namen in OpenXML zijn totaal niet consequent wat betreft hoofdlettergebruik
-OpenXML rept over standaarden die niet nader uitgelegd worden, wat niet gebruikelijk is in een standaard,
-OpenXML maakt praktisch geen gebruik van bestaande standaarden, maar definieert eigen standaarden, wat voorkomen moet worden in standaarden,
-OpenXML is 5 x zo snel tot ECMA standaard gemaakt dan in de industrie gebruikelijk, daarom kan de standaard nooit zorgvuldig tot stand gekomen zijn,
-Het is voor standaardiesatie-organen niet te doen 6000 pagina's in vijf maanden (verkort proces) tijd door te nemen, aanmerkingen te maken, verbeteringen op te stellen en door te voeren en deze goed te keuren.
-De EU doet mogelijk nog een anti-trust onderzoek naar de gesloten bestandsformaten van Microsoft.

Verder is de Japanse standaardorganisatie nog bezorgd over de legale status van deelimplementaties, en vraagt de Duitse DIN zich af waarom Microsoft geen aanvullende standaard kan maken op ISO 26300 (ODF) in plaats van met een overlappende standaard te komen (wat volgens ISO niet mag). Singapore zegt (terecht) dat een 6000 pagina's tellende standaard 3e partijen ophoudt / onnodig verward bij het begrijpen van de standaard, dus dat deze onnodig lang is.

De vraag is dus of Microsoft blij moet zijn met de versnelde procedure.

[Verwijderd]

OpenXML maakt praktisch geen gebruik van bestaande standaarden, maar definieert eigen standaarden, wat voorkomen moet worden in standaarden

OOXML herbruikt ongeveer net zo veel ISO standaarden als ODF. ODF gebruikt misschien wat meer W3C standaarden maar dat is niet relvant tijdens ISO standaardisatie omdat W3C standaarden ook regelmatig ISO negeren (bijvoorbeeld SVG).

-OpenXML heeft, anders dan Microsoft beweerd, niets te maken met backwards compability, omdat de macro's uit oude office versies er niet in gespecificeerd zijn

Macro's zijn een scripttaal en dat is wat anders dan een documentformaat. Macro's zijn uitvoerbare code en dat is wat anders dan office document data.
Weliswaar kun je in een document macro's ter aanvulling van de office data gebruiken maar dan hoeven deze nog geen deel te vormen van het formaat. Plaatjes zoals jpeg kun je ook aan een document toevoegen maar documentformaten bevatten ook geen definites van jpeg. Overigens bevat ook ODF geen macrotaal.

-OpenXML is 5 x zo snel tot ECMA standaard gemaakt dan in de industrie gebruikelijk, daarom kan de standaard nooit zorgvuldig tot stand gekomen zijn,

Ecma is een organisatie die bestaande industrietechnologie standaardiseert. OOXML is gebaseerd op de reeds bestaande XML formaten uit MS Office (voor het eerst opgenomen in 2002). Ecma heeft de formaten dus niet zo maar uit het niets gecreerd maar bestaande technologie asl basis gebruikt.

Het is voor standaardiesatie-organen niet te doen 6000 pagina's in vijf maanden tijd door te nemen, aanmerkingen te maken, verbeteringen op te stellen en door te voeren en deze goed te keuren

Dat is ook helemaal niet nodig. Omdat bij fasttracking de standaard vanuit bestaande technologie is voortgekomen en omdat het beheer van de standaard niet zit bij ISO moet ISO niet elke markup elementje afzonderlijk controleren. Het gaat er met name om of de bestaande technologie een door de markt gewenste ISO standaard is en of de Ecma standardisatie en beheer van de standaard vervolgens voldoen aan de kwaliteitseisen van ISO.

[Verwijderd]

OOXML herbruikt ongeveer net zo veel ISO standaarden als ODF. ODF gebruikt misschien wat meer W3C standaarden

Dat is niet waar, ODF gebruikt waar relevant bestaande ISO standaarden, en een van de kritieken op OOXML is dat die dat niet doet op punten waar ODF dat wel doet. Daarnaast gebruikt het ook W3C standaarden, maar je hebt wel een punt als je suggereert dat dat niet relevant is, het gaat hier nl. over de ISO, niet de W3C.

maar dat is niet relvant tijdens ISO standaardisatie omdat W3C standaarden ook regelmatig ISO negeren (bijvoorbeeld SVG).

"Maar mamma hij pakte mijn lollie af! ." Dat boeit dus totaal niet. Het gaat er simpelweg om dat het verschillende organisaties zijn. Het lijkt me overigens zelfs dan een plus als standaarden gedeeld worden, bijvoorbeeld als bepaalde standaarden zowel een ISO als een W3C standaard zijn, of zouden kunnen zijn (kwalitatief gezien).

Op dit soort punten moet je in de toekomst kijken en denken (als voorbeeld): hoe maken we ons leven over 50 of 500 jaar niet een complete hel als we proberen om al die 1tjes en 0tjes op die rechthoekige disken te begrijpen om te kijken wat men 50 of 500 jaar terug in de geschiedenis deed?

[kidde]

Alleen programmeurs zullen mogelijk de xmltagging zien en die vinden vast
{1}<w:bgcolor> prettiger dan {2}<WordprocessingML:BackgroundColor>

Hier ga je samen met Microsoft de mist in.
Volgens de XML spec. op basis van SGML (ISO 8879) is het de bedoeling dat mensen makkelijk kunnen lezen wat er bedoeld wordt; de XML moet 'human readable zijn'. In de praktijk betekent dat dat je geen klinkers weglaat.

Voor de standaarden waarvan gezegd wordt "doe het als applicatie X", maar waar niet in de 6000+ pagina's staat hoe dat moet, het volgende:
autoSpaceLikeWord95, footnoteLayoutLikeWW8, mwSmallCaps, shapeLayoutLikeWW8, suppressTopSpacingWP, truncateFontHeightsLikeWP6, uiCompat97To2003, useWord2002TableStyleRules, useWord97LineBreakRules, wpJustification.

Ook al zijn deze elementen optioneel, backwards compability door software die niet door MS is gemaakt wordt niet bereikt door naar het gedrag van deze (binaire) applicaties te verwijzen, maar niet te zeggen hoe dat dan is, zodat reverse engineering nodig is dit te achterhalen. Reverse engineering is echter volgens de EULA's van desbetreffende software verboden, en dus is het effectief onmogelijk bovenstaand gedrag na te bootsen.
Verder verwijst MS op de koop toe naar RTF, MHTML, 'earlier versions of WordProcessingML', en Bitmap, EMF en WMF. Hiervoor geld hetzelfde: op eentje na proprietary formaten van MS; nergens in de nieuwe standaard is een verwijzing te vinden hoe deze opgebouwd zijn.
Samen met het slordige gebruik van hoofdletters en kleine letters door elkaar, vindt ik dat zeker genoeg argumenten om het een baggerstandaard te noemen.

Het is zeer dom van Microsoft (en voor on-achterdochtige mensen onbegrijpbaar) niet voort te bouwen op / aan te vullen bij ISO 26300 dmv. haar lidmaatschap in OASIS.
Dit scheelt ze (en de consument) geldt, moeite, twee incompatibele standaarden over hetzelfde onderwerp, verwarring bij gebruikers, en hierdoor zou MS Office ook compatibel worden met het Chinese UOF (Bestandsformaat met nadruk op bruikbaarheid voor Aziatische talen, wordt onderdeel van ODF).

De enige reden die Microsoft kan hebben om geld over de balk te smijten om een brakke implementatie van een bestaande ISO standaard te willen laten ISO-stempelen en haar eigen klanten te verwarren, en één enkele standaard te onthouden, is dat men concurrentie wil belemmeren, oa. door ervoor te zorgen dat OOXML wél, en ODF niet compatibel is met oude binaire MS-Office / WP documenten.

Zo simpel is het: Bij ODF bekvechten de partijen over hoe de implementatie moet, wat aangeeft dat er concurrentie mogelijk is. Bij OpenXML echter, staat alles vast, en bestaande partijen lopen effectief 6000 pagina's achter op MS-Office2003 bij het implementeren van OOXML (nog afgezien van het feit dat men bepaalde binaire delen van formaten moet 'emuleren'); concurrentievervalsing dus, en een belemmering voor een vrije marktwerking.

Dan heb ik liever (en iedereen die voor een vrije marktwerking is met mij) dat er gebekvecht wordt over hoe het nou moet, wat al aangeeft dat OpenOffice niet de referentie is. Voor OOXML zal MS-Office echter effectief de referentie zijn.

[Verwijderd]

Dat is niet waar, ODF gebruikt waar relevant bestaande ISO standaarden,

Een fabeltje. in de ODF standaard worden nauwelijks ISO standaard hergebruikt maar voornamelijk webstandaarden die niet aan ISO zijn voorgelegd.

Miquel de Icaza (Novell/Mono) heeft ze al handig voor me geteld. van zijn blog:

ODF only references three ISO standards: Relax NG (OOXML also references this one), 639 (language codes) and 3166 (country codes).

[Verwijderd]

Dat boeit dus totaal niet.

Dat boeit in zoverre dat het voor ISO blijkbaar geen bezwaar was als ODF de de ISO standaard voor vector graphics negeert en ISO daar geen opmerking over heeft dat dat dan een precedent schept voor OOXML om ook de ISO standaard voor vector graphics te negeren.

[Little Penguin]

@hal:
Mijns inziens gaat het ook niet om wie de meeste ISO standaarden (her)gebruikt, dat is alleen maar leuk voor de statistieken.

Wat vooral belangrijk is, dat is welke standaard het best aansluit bij het idee achter XML en welke standaard het best probeert aan te sluiten op de toekomst.

MS OOXML is toch vooral een voortzetting van de bestaande binaire formaten en is daarmee vooral op het verleden gericht.

/me Penguin zit overigens nog wel te wachten op onderbouwt commentaar op de andere punten die kidde opvoert - die zijn namelijk erg relevant voor een XML-office standaard die 30+ jaren mee moet kunnnen....

[Verwijderd]

Little Penguin zit overigens nog wel te wachten op onderbouwt commentaar op de andere punten die kidde opvoert - die zijn namelijk erg relevant voor een XML-office standaard die 30+ jaren mee moet kunnnen
Kidde heeft wat argumenten toegevoegd geloof ik.

Uit zijn post:

Verder is de Japanse standaardorganisatie nog bezorgd over de legale status van deelimplementaties,

Heel vreemde opmerking van de Japanse organisatie dan want OOXML bevat een heel duidelijke conformance sectie die veel duidelijker dan bijvoorbeeld bij ODF omschrijft wat je moet doen om aan de OOXML standaard te conformeren. In het kort komt het er op neer dat je conformerende deelimplementaties kan maken (of zelfs de standaard extenden met custom schema's) als je maar duidelijk aangeeft wat wel of niet ondersteunt wordt. Waarom heeft de Japanse standaardsorganisatie geen issue gemaakt van de supervage conformance in ODF clausule toen ODF werd gestandaardiseerd ? Dit is eigenlijk lachwekkend want dit onderdeel is in ieder geval bij OOXML een STUK BETER dan bij ODF geregeld !!!

en vraagt de Duitse DIN zich af waarom Microsoft geen aanvullende standaard kan maken op ISO 26300 (ODF) in plaats van met een overlappende standaard te komen (wat volgens ISO niet mag

Dat is een onjuiste interpretatie van Kidde. Overlappende standaarden mogen best. Alleen standaarden die conflicteren mogen niet. Voorbeeld, een standaard die een standaard ISO maat een andere definitie geeft, bijvoorbeeld een meter definieren als een zoveelste deel van de hoogte van de eiffeltoren. Rick Jeliffe (lid van ISO JCT1/SC34) heeft er een paar goede blogartikelen over geschreven.

Singapore zegt (terecht) dat een 6000 pagina's tellende standaard 3e partijen ophoudt / onnodig verward bij het begrijpen van de standaard, dus dat deze onnodig lang is.

Dat is volgens mij niet een terechte opmerking. Er wordt vaak vergeleken met de ODF standaard maar deze is sowieso al compacter qua lay-out maar bevat ook veel minder voorbeelden dan OOXML en vereist ook nog eens implementatie van de halve set aan w3c specs. Het is ook nog steeds twee jaar na standaardisatie geen enkele applicatie gelukt om de slechts 700 pagina's tellende ODF spec volledig te implementeren. Implementatie van een Office standaard is dus een mega klus en dan is juist een uitgebreide spec met veel voorbeelden veel handiger dan een kleinere spec met relatief weinig implementatievoorbeelden. Bij ODF worden momenteel enorme inspanningen geleverd om de spec te interpreteren en om testsuites en validatietools te bedenken puur omdat de spec zoveel ruimte laat voor interpretatie en er daarom nog geen interoperability is tussen de verschillende implementaties.

Nog meer ?

[Verwijderd]

Als ECMA standaard 376 echt zoveel standaarden herbruikt, was deze nooit 6000 pagina's lang geweest

OOXML gebruikt niet veel meer ISO standaarden dan ODF.

OOXML specificatie kan ook een stuk kleiner denk ik.
* Er zitten wel misschien wel duizend of meer pagina's voorbeelden in die eruit kunnen.
* Er zit 600 pagina's deprecated VML in waarvoor ze ook de oude w3c draftversie als referentie hadden kunnen opnemen.
* Ze hadden net als bij ODF de linespacing kleiner (1:1,5) kunnen maken en daarmee minder pagina's kunnen krijgen.
* Ze hadden de voor implementatie zeer handige referentietabellen met child/parent elements kunnen laten vervallen.
* Ze hadden deprecated elementen voor legacy compatibility in een annex kunnen opnemen of impmentatiespecifiek laten (zoals ODF heeft gedaan) en weer een paar honderd pagina's minder kunnen hebben. * Verder bevat ODF tervergelijking natuurlijk geen formula's die in OOXML toch wel een pagina of 500 innemen. Die had OOXML ook wel als aparte standaard kunnen introduceren
* Evenzo bijvoorbeeld de 1300 pagina's DrawingML of de OpenPackaging conventie die ten slotte ook al in de XPS standaard is opgenomen

Tja, het kan kleiner, en misschien zelfs wel minder dan de helft maar kleiner voegt niks toe. Je verplaats alleen maar issues naar de implementaties omdat de essentie van de inhoud hetzelfde blijft.

Bovendien worden bij OOXML alle elementen nu onderdeel van een ISO standaard terwijl bij ODF veel elementen die in de spec gerefereerd worden helemaal niet ISO gestandaardiseerd zijn.

[Verwijderd]

@Little Penquin

-OpenXML houdt zich niet aan algemeen aanvaarde XML-afspraken wat betreft leesbaarheid

Ik vind dit een onzin issue. Er zijn geen duidelijke afspraken waarop ik dit kan afrekenen. Bovendien betreft het hier een volledig gestandaardiseerd formaat dat altijd door software wordt geimplementeerd. Er is geen menselijke interpretatie nodig. Alleen programmeurs zullen mogelijk de xmltagging zien en die vinden vast <w:bgcolor> prettiger dan <WordprocessingML:BackgroundColor>
(verzonnen voorbeeld)

[quote]
OpenXML conflicteert met meerdere ISO standaarden (waaronder de eeuwenoude Gregoriaanse kalender, papierformaten en kleuren)[quote]Dat is niet juist. OpenXML gebruikt met name de w3c XML standaarddatum, een subset van ISO 8601. Alleen in SpreadsheetML, een markup taal voor gebruik in spreadsheets worden twee numerieke datumtypes toegepast die niet conflicteren maar gewoon compatible zijn met de ISO datums. Alleen in 1 van die twee formaten, het datum 1900 formaat, wordt ten onrechte 60 gebruikt voor 29-feb-1900. Dat is dan wel afwijkend maar laat wel toe dat daarmee oude spreadsheets volledig goed kunnen worden geinterpreteerd.
Bij papierformaten wordt door OOXML de ISO standaard zelfs gedeeltelijk hergebruikt (in ODF bijvoorbeeld helemaal niet !!!). Er worden ook niet ISO papierformaten in de standaard genoemd maar dat is aanvullend en niet conflicterend. Er worden nu eenmaal meer papierformaten toegepast in de officewereld dan alleen de ISO formaten. ODF past een flexibel papier formaat toe waardoor de papierformaten helemal niet zijn gestandaardiseerd. Dit wordt allemaal aan implementatie overgelaten. Dit is flexibel maar dramatisch slecht voor de interoperabiliteit.
Wat betrreft de kleuren gebruikt OOXML de ISO kleuren maar heeft een meer intern consistente naamgeving gebruikt. Iets met maroon/darkred of zoiets. Dat is dus niet conflicteren maar 100% compatibel.

-OpenXML rept over standaarden die niet nader uitgelegd worden, wat niet gebruikelijk is in een standaard

Is dit een serieus argument ? Ik begrijp niet wat hier wordt bedoeld.

OpenXML maakt praktisch geen gebruik van bestaande standaarden, maar definieert eigen standaarden, wat voorkomen moet worden in standaarden,

ODF gebruikt weliswaar een paar w3c standaarden meer dan OOXML maar niet meer ISO standaarden en dat lijkt me relevant in een ISO standaardisatie. En bijvoorbeeld hergebruik van MathML is helemaal geen logische standaard voor een edit formaat. Dat is een presentatieformaat voor webpagina's. En bij bijvoorbeeld SVG was de standaard te beperkt voor ODF en daarom heeft ODF deze standaard geextend met eigen elementen specifiek voor ODF. Een soort SVG++. Lastig als w3c ooit iets anders wil met SVG !!

-Variabele-namen in OpenXML zijn totaal niet consequent wat betreft hoofdlettergebruik

Geen idee.

[Little Penguin]

@hal:
Aangezien je kwooting enigszins van slag lijkt te zijn reageer ik maar even zonder quotes:
Voor zover ik weet is het de bedoeling dat de XML element- en attribuutnamen zelfuitleggend zijn - in OO XML worden nog al eens afkortingen gebruikt. En, om in te gaan op je voorvbeeld, namespaces zijn volgens mij nooit een onderdeel van een XML-definitie.

Inzake het niet volgens de ISO standaarden werken: Als er uitbreidingen zijn op de ISO standaard, die in geen enkele andere algemene (ISO) standaard genoemd zijn dan heb ik daar geen problemen mee. Inzake (ja ik kom er steeds weer op terug) de 1900-schrikkeljaar bug: Waarom is het zo moeilijk om deze bug bij het serializen vanuit MS-Office om zeep te helpen? Dan hou je de standaard clean!.

Over de niet gedocumenteerde standaarden: Ik denk dat kidde (en het Keniaanse standaard instituut) doelen om de diverse verwijzingen naar (MS) standaarden die niet publiek beschikbaar zijn.

Over SVG++:
Ik ben het met je eens dat men aan 'extend' doet als men een eigen SVG standaard definieert, maar als men die volgende de XML-regels gedaan heeft hoort een toekomstige uitbreiding door het W3C niet voor problemen te zorgen.

Ook ODF is niet perfect en is zeker voor verbetering vatbaar, maar ik denk dat men dan beter samen kan werken aan een uitbreiding op ODF zodat ook MS er tevreden mee kan zijn. Een soort 'ODF Strict' en een 'ODF Transitional', net zoals bij HTML gedaan is - waarbij je dus kunt kiezen om naat het verleden te werken of juist naar de toekomst...

Als men niet tig verwijzingen in de standaard naar het office verleden opgenomen zou hebben dan zo OO XML misschien wel een werkbare standaard kunnen worden.

Nu ben ik overigens niet zo gecharmeerd van de non-mixed content opmaak van OO XML, maar goed dat is puur persoonlijk...

[Verwijderd]

@kidde

Perfectie wordt niet bereikt als er niets meer is toe te voegen, maar als er niets meer is weg te laten; met name als het om standaarden gaat.

Perfectie is maar relatief:
ODF heeft de formula spec weggelaten en tabellen in presentaties en digitale siggnatures
Hoe is dat perfect te noemen ? (wel klein)
ODF heeft compatibility issues weggestopt in implementatie specifieke elementen die per definitie niet uniek en/of interpretabel zijn.
Is dat perfect ?
ODF heeft de SVG spec deels gerefererd en deels gekopieerd in de spec. Daardoor kun je bijvoorbeeld SVG plaatjes niet zonder conversie native intergreren in ODF maar alleen als extern object embedden terwijl je vector elementen uit ODF juist weer niet als SVG plaatje kan exporteren.
Is dat perfect ?

Verder heb ik al aangegeven dat de meeste dingen die je weglaat geen effect hebben op wat je moet implementeren. Alleen de voorbeelden zou je echt als overbodige ballast kunnen zien omdat ze theoretisch extra fouten kunnen toevoegen. Echter voor implementatie zijn deze voorbeelden wel een groot voordeel.

Er zit 600 pagina's deprecated VML in waarvoor ze ook de oude w3c draftversie als referentie hadden kunnen opnemen.
Dan hadden ze dat zeker moeten doen.

Dat vind ik eigenlijk ook wel (daarom noemde ik het natuulijk ook). Ik neem echter aan dat w3c drafts niet echt genoeg status hebben als referentie.

[kidde]

Miquel de Icaza (Novell/Mono) heeft ze al handig voor me geteld... ...ODF only references three ISO standards:

Refereren is niet gelijk aan gebruiken. Pak een willekeurig patent, en je ziet dat er zo 50 patenten (veelal van andere bedrijven) gerefereerd worden. Deze worden echter niet gebruikt in dat patent, want dat is inbreuk op IP.
Men kan namelijk zeggen: Kijk daar, maar wij doen het anders (refereren maar niet gebruiken).
Als ECMA standaard 376 echt zoveel standaarden herbruikt, was deze nooit 6000 pagina's lang geweest.

[Little Penguin]

@hal:
Jazeker, en dan met name deze:

-OpenXML conflicteert met meerdere ISO standaarden (waaronder de eeuwenoude Gregoriaanse kalender, papierformaten en kleuren)
-OpenXML houdt zich niet aan algemeen aanvaarde XML-afspraken wat betreft leesbaarheid
-Variabele-namen in OpenXML zijn totaal niet consequent wat betreft hoofdlettergebruik
-OpenXML rept over standaarden die niet nader uitgelegd worden, wat niet gebruikelijk is in een standaard,
-OpenXML maakt praktisch geen gebruik van bestaande standaarden, maar definieert eigen standaarden, wat voorkomen moet worden in standaarden,

Ik ben vooral een techneut en als techneut ben ik vooral geinteresseerd in relevante technische issues - daar ben je niet echt op ingegaan, ik denk dat die issues juist opgelost moeten worden.

Verder is vanuit een Europees standpunt zaken als 'software-patenten' niet zo interessant, hoe daar mee omgegaan wordt is me dus om het even - uiteraard zolang de EU het zogenaamde 'software-patent' buiten de wet en regelgeving houdt.

Inzake de lengte van de specificatie:
In een eerder bericht op tweakers.net is dat al aan de orde geweest, uiteindelijk is die (netto) voor ODF ongeveer net zo lang als die voor OOXML - als je alle documenten bijelkaar veegt voor ODF kom je aan een vergelijkbare grote.

Inzake de totale implementatie van ODF in een office applicatie: Zie Acid2 vs Mozilla Firefox - project planning is dus ook een issue dat je mee zal moeten nemen.

Als OpenOffice.org 3 ODF niet volledig ondersteund heb je wat mij betreft een punt...

[kidde]

OOXML is gebaseerd op de reeds bestaande XML formaten uit MS Office (voor het eerst opgenomen in 2002). Ecma heeft de formaten dus niet zo maar uit het niets gecreerd maar bestaande technologie asl basis gebruikt.

Dus als ik met grote haast een boek van 6000 pagina's schrijf over de bestaande Amsterdam ArenA, heb ik dat ook niet uit het niets gehaald, maar omdat de ArenA al bestaat kan ik dat boek veel sneller nakijken dan een boek over een nieuw gebouw, dat niet met haast geschreven is? Lijkt me onzin. Als een gebouw goed is kan het boek best bagger zijn. In het geval van OpenXML is dat zo: Het formaat werkt misschien voor de industrie, maar de standaard is bagger.

maar kleiner voegt niks toe.

Zeer zeker wel. Perfectie wordt niet bereikt als er niets meer is toe te voegen, maar als er niets meer is weg te laten; met name als het om standaarden gaat. Hoe lijviger een standaard, hoe meer fouten en tegenspraken deze kan bevatten. M'n NEN-bundel 16, die maar 700 pagina's telt die in een veel langere termijn behandeld zijn dan 5 maanden, bevat al een hoop tegenstrijdigheden.

Het is ook nog steeds twee jaar na standaardisatie geen enkele applicatie gelukt om de slechts 700 pagina's tellende ODF spec volledig te implementeren

Kan je nagaan hoe lang het voor 6000 pagina's duurt.

...een overlappende standaard te komen (wat volgens ISO niet mag... ...Dat is een onjuiste interpretatie

Niet verboden, wel hooguit onwenselijk. De DIN zij vooral dat ECMA 376 met ISO 26300 conflicteert, en dat komt door de overlap.
Wenselijk is daarom dat de ECMA en OASIS samen gaan werken, maar hier heb ik nog niks van vernomen. Opgemerkt dient te worden dat Microsoft al lid is van OASIS.

maar dan hoeven deze (macro's red.) nog geen deel te vormen van het formaat.

In de praktijk zijn ze dat wel; ze zitten immers (voor zover ik weet) ingebakken in de .doc etc. bestanden. In dat geval is OpenXML niet backwards compatible.

Ecma is een organisatie die bestaande industrietechnologie standaardiseert

Daarom is de standaard ook zo brak: Normaal maak je een standaard en dan de implementatie (bv: Bij ODF is men na 2 jaar nog bezig aan de implementatie, zoals je zelf zegt, bij ECMA376 bestond de implementatie voordat de standaard bestond).

worden bij OOXML alle elementen nu onderdeel van een ISO standaard

Dat is niet echt wenselijk denk ik, men had er beter aan gedaan verschillende standaarden te maken bij de verschillende afzonderlijke onderdelen.

Er zit 600 pagina's deprecated VML in waarvoor ze ook de oude w3c draftversie als referentie hadden kunnen opnemen.

Dan hadden ze dat zeker moeten doen.

[Verwijderd]

@kidde

maar dan hoeven deze (macro's red.) nog geen deel te vormen van het formaat.
In de praktijk zijn ze dat wel; ze zitten immers (voor zover ik weet) ingebakken in de .doc etc. bestanden. In dat geval is OpenXML niet backwards compatible

Plaatjes of mulltimedia toevoegingen zitten ook in de huidige .doc files ingebakken. Dat maakt ze nog geen onderdeel van de spec.

[Verwijderd]

Het formaat werkt misschien voor de industrie, maar de standaard is bagger.

Dat is gewoon onzin. De OOXML standaard is helemaal geen bagger.

[ppl]

@hAl

Heel vreemde opmerking van de Japanse organisatie dan want OOXML bevat een heel duidelijke conformance sectie die veel duidelijker dan bijvoorbeeld bij ODF omschrijft wat je moet doen om aan de OOXML standaard te conformeren.

Of je leest het verkeerd. Wordt er hier niet deelimplementaties van de betreffende standaard zelf bedoeld (dus OOXML en niet iets anders)? Waar men hier ook op kan doelen is het gebruik van patenten en technieken van derden. In dat geval is het dus inderdaad een goede vraag of hier legaal gebruik van wordt gemaakt. Men zit niet te wachten op weer zo'n soap als dat van SCO.

Het is ook nog steeds twee jaar na standaardisatie geen enkele applicatie gelukt om de slechts 700 pagina's tellende ODF spec volledig te implementeren.

Je verkijkt je hier wel enorm op. De ODF spec die jij noemt mag dan wel 2 jaar oud zijn, maar is die gelijk aan de spec die ECMA heeft goedkeurt en is die ook gelijk aan hetgeen ISO heeft goedgekeurd? Er zijn zat instanties die pas sinds het officiele bericht dat ODF een officiele ISO standaard is geworden er mee begonnen zijn. De meesten wilden dit afwachten. Sommigen zijn nog afwachtender en wachten ook nog af wat het ISO met OOXML gaat doen. Een voorbeeld hiervan is onze eigen EU die wacht met het schrijven van richtlijnen op dit gebied totdat er duidelijkheid is over de toekomst van OOXML. Op z'n hoogst hebben we het hier dus over een half jaar na standaardisatie en beslist niet over 2 jaar. Kennelijk bevalt het een aantal instanties zo goed dat ze er al mee begonnen zijn.

Dat is ook helemaal niet nodig. Omdat bij fasttracking de standaard vanuit bestaande technologie is voortgekomen en omdat het beheer van de standaard niet zit bij ISO moet ISO niet elke markup elementje afzonderlijk controleren. Het gaat er met name om of de bestaande technologie een door de markt gewenste ISO standaard is en of de Ecma standardisatie en beheer van de standaard vervolgens voldoen aan de kwaliteitseisen van ISO.

Als je een orgaan iets vraagt om te standaardiseren dan is het wel zo handig dat het ook weet wat het precies als standaard uitroept. Dat betekent dat je dingen door moet kijken en waar nodig toetsen. Dat zijn dingen die je niet zomaar eventjes doet, daar heb je een bepaalde tijd voor nodig. Vaak heb je een heel proces waarin je diverse review/inspection rondes hebt e.d. Dat kost aardig wat tijd allemaal. Je zult een aantal zaken waarschijnlijk wel inhoudelijk willen toetsen en weten hoe dingen juridisch staan. Zeker met de hedendaagse patent- en auteursrechtpraktijken.

Kortom, als er iets is wat het ISO juist WEL moet doen dan is het controleren van ieder markup elementje. Dat heeft ook alles te maken met het begrip "kwaliteit". Snelheid is dus leuk en aardig maar kan wel degelijk flink van je kwaliteit afsnoepen Men zegt niet voor niets "haastige spoed is zelden goed". Het is alleen niet juist om op te merken dat het helemaal niet nodig is. Het is juist van cruciaal belang wil je een fatsoenlijke standaard hebben. Ik denk dat het ISO zich hier ook wel degelijk van bewust is en dat ook naleeft.

[Little Penguin]

Hier ga je samen met Microsoft de mist in.
Volgens de XML spec. op basis van SGML (ISO 8879) is het de bedoeling dat mensen makkelijk kunnen lezen wat er bedoeld wordt; de XML moet 'human readable zijn'. In de praktijk betekent dat dat je geen klinkers weglaat.

Voor het geval hAl zich afvraagt waar dat je dit precies kunt vinden, het staat in de paragraaf Origin and Goals van de XML specificatie.

Wat daar (ook) expliciet genoemd staat, dat is:

Terseness in XML markup is of minimal importance.

, iets dat dus niet gevolgd wordt in OOXML.

Correctie van hAl's Voorbeeld:
<w:r>
<w:rPr>
<w:i />
</w:rPr>
<w:t>with some</w:t>
</w:r>

Dit is dus wel compact, maar niet human readable - de gemiddelde lengte van XML namelijk mag best wat langer zijn.

Want: Zowel in OOXML als ODF wordt het uiteindelijk toch gezipt - waarbij beide formaten een vergelijkbare bestandsgrote opleveren,
winst voor de compactheid: geen, het is alleen minder leesbaar voor een programmeur die het moet uitlezen of moet wegschrijven, dus grotere kans op fouten...

[Verwijderd]

@kidde

Het is zeer dom van Microsoft (en voor on-achterdochtige mensen onbegrijpbaar) niet voort te bouwen op / aan te vullen bij ISO 26300 dmv. haar lidmaatschap in OASIS

Het zou heel naief zijn on dat zelfs maar te proberen. OpenDocument ontwikkeling is volledig onder controle van Sun/OpenOffice. Er is geen schijn van kans dat Microsoft voor hen en hun klanten belangrijke issues als backwards compatibiliteit met de miljarden legacy documenten op de agenda krijgt.

Wat zeer dom is en voor achterdochtige mensen onbegrijpbaar is dat men is begonnen met standaardisering van Office formaten zonder de marktleider in Office documenten aan de tafel uit te nodigen. De eerste actie van het OASIS committee op de openingsbijeenkomst voor het creeren van een Open Office XML formaat was het starten met het formaat van OpenOffice en vast te leggen dat er geen compatibiliteit met de formaten van Microsoft Office hoefde te zijn.

Verder heeft Sun bijvoorbeeld hun patentrechten voor volgende versies van ODF niet zonder meer vrij gegeven. Na het decable met mp3 rechten waarvoor MS met een boete van een miljard of zo is geconfronteerd zal MS zeker geen formaten gebruiken waarvan ze zelf niet kunnen garanderen de rechten te hebben ook naar de toekomst.

[Jungian]

En backwards compatibility heeft in welk opzicht te maken met ODF of OOXML ? Microsoft had prima ODF kunnen gebruiken, of dat uit kunnen breiden. En als ze het toch nodig vinden te verwijzen naar binary blobs kunnen ze ook best wel eens alle documentatie daarvan vrijgeven, dan zal je een stuk minder mensen horen klagen. Binary bestandsformaten zijn zo 1983.

[Little Penguin]

OpenDocument ontwikkeling is volledig onder controle van Sun/OpenOffice. Er is geen schijn van kans dat Microsoft voor hen en hun klanten belangrijke issues als backwards compatibiliteit met de miljarden legacy documenten op de agenda krijgt.

Ik vraag me af of ze het wel geprobeerd hebben, want: Patrick Gannon, de CEO van OASIS heeft hierover op 14 december 2005 het volgende gezegd:
"The OASIS OpenDocument Technical Committee remains open to new participation and contributions. Obviously, Microsoft's expertise in office applications would make them a great asset to the committee, and we continue to encourage them to participate in this effort,"

Bron: http://www.eweek.com/article2/0,1895,1901967,00.asp

[Verwijderd]

wakker worden, Jungian.
De enige gedefinieerde binary blob in OOXML is de digitale signature.

Overigens bevat ODF ook gewoon binary data elementen. Je mag er alles instoppen

[Verwijderd]

Je kon ook eigenlijk niet in deze eerste fase de voortgang dwarsbomen. Het was gewoon een periode waarin een contradictions review plaats kon vinden door de aangesloten nationale standaardorganen.
Op basis daarvan kan het JCT1 committe de indiener hoogstens adviseren om hun voorstel terug te trekken. Er was echter geen stemming of een formele afwijzings of goedkeurings moment.
Het JCT1 committee heeft echter geen aanleiding gezien om negatief te adviseren en Ecma heeft de opmerkingen uit de contradictions review beantwoord in een response document.

[Little Penguin]

Uit het originele (pers)bericht:

The JTC 1 Secretariat informed Ecma International today that Office Open XML will move immediately to the next phase of the ISO/IEC’s review of the Ecma standard.

Het gaat dus om versnelde ISO goedkeuring, versnelde ECMA goedkeuring zou inderdaad erg vreemd geweest zijn.

Ik neem aan dat er uiteindelijk over de standaard gestemd zal worden door de ISO/IEC leden - hopenlijk houden de huidige tegenstanders hun poot stijf zolang er qua inhoud niks verbeterd. (Reden: Zie mijn reactie hierboven)

/me Penguin vond het bericht hier op tweakers.net ook niet erg duidelijk...

[E-jey]

wow, lijkt wel op of hAl betaald word om OpenXML te verdedigen. Verder is het natuurlijk gestoord dat er niet gewoon 1 standaard gemaakt kan worden. Waarom heeft MS odf neit gewoon verbeterd? Volgensmij word het tijd dat de overheden gaan ingrijpen. De wereld is heel erg gebaat bij duidelijke open standaarden. Er spelen alleen veel te veel belangen mee overal. Als de EU eens 100miljoen investeert in open standaarden. Dat is 1/5 van de boete die ms laatsts gekregen heeft. Dat moet toch niet zo'n probleem zijn.

Neelie Kroes slaat ook de plank volledig mis. Die zit een beetje te piepen of een media player die met windows geleverd word. Dat komt omdat ze alleen naar anderen klagende bedrijven luistert (real) en niet naar het totaal plaatje kijkt. Eigenlijk zouden alle formaten waarmee informatie uitgewisseld word, open moeten zijn. Bedrijven moeten concurreren met producten en niet elkaar uitsluiten door gesloten formaten te gebruiken. Dit probleem gaat alleen maar groter worden.

Soms denk ik wel eens na over wat er was gebeurd als grote bedrijven zich hadden bemoeit met de ontwikkeling van het internet. Grote kans dat er in plaats van html/http een gesloten protocol/formaat was geweest. Nieuwe technieken zoals flash zijn ook allemaal gesloten.

[kidde]

wow, lijkt wel op of hAl betaald word om OpenXML te verdedigen.

Vroeger deed Raul Pesch van Microsoft NL dat. Helaas is die de laatste tijd pleitte, omdat sommige Tweakers (helaas) wilden dat hij niet meer reageerde op tweakers (wat ik jammer vind, hij deed het in het openbaar, met toenaam en bedrijf erbij)
Echter, er is geen bewijs, dus geen beschuldigingen aub.
We weten alleen dat 'anderen' door MS betaald werden om op Wikipedia voordelige dingen over OpenXML te vertellen.
Dat hAl ook vele bijdragen op Wikipedia heeft gedaan aan OpenXML, met name ten faveure van OpenXML - en anderen op Wikipedia hem beu werden (

"
Enough with the personal attacks HA1".

sic.)- zegt natuurlijk niks. Van hAl zelf heb ik vernomen dat de personen die hem beu werden 'bevooroordeeld' waren, en dat een 'heethoofd als ik' niet zou begrijpen dat hij meehielp aan een Neutral Point of View.
Erg imposant te zien hoeveel gebruiker hAl heeft bijgedragen aan de discussie op Tweakers, maar ook op Wikipedia, en hij verdient respect (en een laptop met kerstmis!) daarvoor, geen valse beschuldigingen.
Disclaimer: Zelf ben ik onbetaald vrijwillig amateur-redacteur/schrijver voor een Linux-newssite, hetgeen netjes op m'n T.net profiel staat.

[Sjaaksken]

wow, lijkt wel op of hAl betaald word om OpenXML te verdedigen

die indruk kreeg ik ook

Btw, er zijn een fors aantal landen die zich afzijdig gehouden hebben of openXML de snelprocedure mocht doorlopen, maar bvb in het geval van België is de situatie veelzeggend:

het beslissingsorgaan voor advies in deze standaardisatieprocedures bestaat in België uit een mengeling van non-profit wetenschappelijke instituren (zoals de universiteit van Leuven) en een vereniging van technologiebedrijven waaronder microsoft. En blijkt nu dat alle onafhankelijke non-profit partijen flagrant tegen een snelle procedure waren, de enigste reden dat er geen advies geformuleerd is is omdat microsoft een te grote stem had in het adviesorgaan. Ik vind het niet minder dan bizar dat een bedrijf zowel een standaard kan voorstellen als in het adviesorgaan zetelen dat een rol speelt binnen het standaardisatieproces. België zal altijd België blijven....

Voor wie mij moeilijk kan geloven:

http://www.zdnet.be/news.cfm?id=65147

[haling]

Het zal (hopelijk) nooit de ISO standaard halen. Dat zou nl erg belachelijk zijn omdat MS in het OpenXML formaat zelf lak heeft aan eerder gestelde ISO normen zoals datum en kleurnotatie.

Ook is het helemaal niet nodig om nog een ISO standaard te hebben als er al een perfecte is??? Zonde van al dat tijd en geld...

De enige die profijt heeft van een standaardisering van het OpenXML formaat is Microsoft zelf...

[RemcoDelft]

Office Open XML

"Office Open" lijkt wel heel veel op "Open Office"... Komen ze hier serieus mee weg?
Als ik een product "DowsWin" of "SoftMicro" noem gaan ze vast ook klagen...

[Stevendefeij]

Doe het dan gelijk echt goed en maak een linux disto met de naam Vista Windows. After all de naam Vista los hoort bij een ander bedrijf in Redmond (die hadden ms ook aangeklaagt en verloren) en Windows hebben we allemaal wel in de muur zitten

[jealma]

Er staat in het nieuwsbericht dat Novell de ooxml ondersteuning al in OpenOffice heeft gebouwd. Wil dit zeggen dat een document, gemaakt met Office 2007, 100% compatibel is met een document dat ik maak onder OpenOffice en opsla als ooxml bestand? Dus ook met tabellen, grafische dingetjes enzo?

[Verwijderd]

Ik denk dat het niveau van de ooxml ondersteuning in OpenOffice nog zeker niet 100% compatibel zal zijn maar een redelijk normaal document zal wel lukken.

[Verwijderd]

@Litte Penguin

Inzake (ja ik kom er steeds weer op terug) de 1900-schrikkeljaar bug: Waarom is het zo moeilijk om deze bug bij het serializen vanuit MS-Office om zeep te helpen?

Toch is er dan geen defnitiemethode mogelijk waarbij een 100% conversie van dergelijke waardes kan bereiken. Het is bijvoorbeeld mogelijk om heel valide spreadsheets hebben die 29-2-1900 (i.e numeriek 60) in het formaat hebben staan. Je kunt dat niet converteren naar een formaat die dat niet heeft.
Zonder een dergelijk formaat kun je met geen mogelijkheid meer een claim doen van volledige compatibiliteit met legacy documenten. Aangezien dat een element is wat in de doelstelling van OOXML staat is dat niet zonder meer irrelevant.

Bovendien is er een dus binnen OOXML een alternatief formaat beschikbaar voor spreadsheet cellen dat geen last heeft van dit issue zodat een implementerende applicatie niet verplicht is om zelf documenten aan te maken die dat issue bevatten.

Het is bovendien ook supersimpel om een conversie te schrijven die (weliswaar dus niet 100%) een conversie kan uitvoeren. 5 regels code ? Als je dus vindt dat het date1900 formaat onzin is kun je je documenten eenvoudig converteren. Ik denk echter dat bijvoorbeeld bij conversies van contracten of wettelijke overeenkomsten een iets hogere standaard vereist is.

[Little Penguin]

Wat te denken van het volgende alternatief?

Bij het saven in OOXML geeft (MS) Office een waarschuwing dat sommige details verloren gaan cq niet goed in OOXML ge-exporteerd kunnen worden. Hierbij kun je zelfs een optie in de toepassing inbouwen om aan te geven welke onderdelen niet naar behoren ge-exporteerd zullen gaan worden.

Op die manier kun je een nette standaard maken en toch het opslaan vanuit (MS) Office mogelijk houden.

Het is dus goed mogelijk om het nieuwe OOXML clean op te zetten, als je de wil hebt om het te doen en het lef om toe te geven -ook naar de eindgebruiker- dat bestaande .xls/.doc features (of bugs) bevatten die niet in OOXML aanwezig zijn...

Problem solved zou ik zo denken...

[Verwijderd]

Wat je dus voorstelt is dat je de backwards compatibiliteit al opgeeft in de standaard.

Dat wat dus juist in de doelstellingen van OOXML staat !!!
Ook bijvoorbeeld geautomatiseerde conversies van spreadsheets worden onmogelijk.

Darnaast leg je niet uit hoe een veld met een dergelijke datum vervangen moet worden. Gewoon maar in het veld #N/B opnemen ? Mogelijk daarmee allerlei afhankelijk berekeningen uitschakelen ?

Verder was mijn voorbeeld slechts dat, een voorbeeld. Deze numerieke datum kan ook verborgen voorkomen (1 + 59). Het kan dus ook nog moeilijk te herkennen zijn.

[Little Penguin]

En hoe moeten de alternatieve implmentaties dan omgaan met die backwards compatibiliteit van MS-OOXML?

Waarmee maar weer duidelijk wordt dat MS-OOXML bedoelt is om het monopolie van Microsoft te versterken...

[Verwijderd]

En hoe moeten de alternatieve implmentaties dan omgaan met die backwards compatibiliteit van MS-OOXML

Of implementeren of geen ondersteuning voor legacy documenten bieden.

Niet implementeren van 100% backward compatibiliteit is voor de meeste implementaties ook geen bezwaar omdat ze dat dus nu ook al niet doen !!!

[kidde]

Het is bijvoorbeeld mogelijk om heel valide spreadsheets hebben die 29-2-1900.

Nee, volgens de Gregoriaanse kalender is dat NIET mogelijk/valide.

[Verwijderd]

Nou en ?
Als ik een spreadsheet maak ben ik toch niet verplicht me aan deze kalender te houden ?
Er zijn verder allerlei denkbare scenario's waarbij gebruik van deze datum in een bestaande spreadsheet kan voorkomen.

[Verwijderd]

Over de niet gedocumenteerde standaarden: Ik denk dat kidde (en het Keniaanse standaard instituut) doelen om de diverse verwijzingen naar (MS) standaarden die niet publiek beschikbaar zijn.

Dat gaat over mogelijk te embedden bestandformaten. Zowel ODF als OOXML hebben geen enkele beperking aan te te embedden formaten in de standaard. Je kunt dus willekeurig elk formaat in je Opendocument of Office Open XML document stoppen. Het is niet logisch dat Microsoft hun eigen formaten zou moeten opnemen in de standaard terwijl bijvoorbeeld dat bij ODF ook niet nodig is. Het is simpelweg zo dat als je embedding van formaten wilt implementeren dat je dan bij ODF en OOXML nu precies dezelfde rechten hebt.

Als MS had toegezegd dat je enkele bij implementatie in OOXML extra patentrechten kreeg op bepaalde formaten dan had iedereen weer geklaagd dat Microsoft probeerde om ODF uit te markt te drukken omdat zij deze rechten niet kunnen verstrekken !!!! (ik zie de commentaren al voor me)

[joho]

Het doel van Microsoft is niet het openbaar en toegangkelijk maken van hun documentstructuur. Er staat duidelijk in de aanvraag voor de standaard dat het de bedoeling is een 1-op-1 vertaling van binair naar XML te maken. Dus standaard is wat hen betreft dus geslaagd als alle documenten te converteren zijn, deze niet door anderen bewerkt kunnen worden, en niet als minste dat dit nieuwe 'open' formaat door alle instanties geaccepteerd zal worden.