Queeste MS voor standaardisering Open XML vertraagd

Het Britse standaardeninstituut heeft protest aangetekend tegen de standaardisering van het Open XML-formaat door de International Standards Organisation. Leden van die raad hadden tot vandaag de tijd om een zogenaamde 'contradiction' in te dienen.

Tegenstanders van het Open XML-bestandsformaat hadden het British Standards Institute verzocht om niet akkoord te gaan met de standaardisering van het door Microsoft ontwikkelde formaat. Een van de reden die daarvoor aangehaald werden, was dat er geen nood is om twee verschillende standaarden in het leven te roepen. Het Open Document Format is door de ISO al goedgekeurd als standaard en dat volstaat volgens aanhangers van dit formaat.

Een woordvoerder van het BSI wilde geen commentaar kwijt over de door zijn organisatie ingediende 'contradiction', maar wilde wel vertellen dat de standaardisering nu met minstens drie maanden is uitgesteld. De ISO moet namelijk de door zijn leden ingediende documenten evalueren en heeft daarvoor negentig dagen de tijd. Een mogelijk gevolg van de 'nee'-stem van het BSI is dat de standaardiseringsaanvraag nu of in de volgende stap van het proces afgekeerd wordt. Een en ander is echter afhankelijk van de ernst van de tegenwerpingen van het BSI: als die niet kritiek van aard zijn, kan de standaardisering alsnog doorgang vinden.

Reacties (67)

Er is al aangetoont dat de ODF standaard vele tekortkomingen heeft, maar i.p.v. die tekortkomingen aan te passen en een betere ODF standaard creëren, zitten ze zich bezig te houden met dit soort pesterijen.

En OpenXML is ook niet optimaal, maar er is opzich niks mis mee met meerdere 'standaarden', uiteindelijk bepaald de markt (consument) wel wat het beste is.

DVD-R en DVD+R zijn uiteindelijk ook keurig beide ondersteund via DVD±R, en zo erg veel werk is het nu ook niet voor een ontwikkelaar om beide bestandsformaten te ondersteunen in hun applicatie. JPEG had ook technische tekortkomingen (geen transparantie), dus nu ondersteunen de meeste grafische applicaties PNG.

@Cyphax, toch gaat OpenXML er komen, standaard of niet, en er zijn al documenten die niet juist vertaald kunnen worden naar ODF toe, simpelweg omdat de ODF standaard hier geen ruimte/specificaties voor heeft. Net zoals de concurentie tussen AMD en Intel veel sneller voor nieuwe ontwikkelingen heeft gezorgt, laat imho datzelfde maar gebeuren voor een bestandsformaat.

Adobe kan er ook nog wel bij, die is namelijk ook bezig met een gelijkwaardige standaard voor documenten afgeleid van PDF.

@dcm360, technisch gezien wel, het zijn beide methodes om een document te bewaren, echter de éné ondersteunt net wat meer dan de ander. Het verschil tussen JPEG en PNG is misschien een betere vergelijking, beide zijn bedoeld om afbeeldingen op te slaan, maar ondersteunen dat op verschillende manieren.

En OpenXML is ook niet optimaal, maar er is opzich niks mis mee met meerdere 'standaarden', uiteindelijk bepaald de markt (consument) wel wat het beste is.

In een normale markt wel. Hier bepaalt Microsoft de markt, niet de consument.

ODF als standaard heeft tekortkomingen van andere aard dan de standaard van Microsoft. De vraag is dan een beetje: welke tekortkomingen vind je zwaarder wegen?
Ik zou gaan voor ODF.

Hoezeer ik ook graag OpenXML zie verdwijnen (nog een formaat om te implementeren, bevat oude legacy meuk die niet gespecificeerd is, etc), heeft ODT toch echt wel ernstige tekortkomingen.

Bijvoorbeeld: ik wil een spreadsheet applicatie ontwikkelen. Dat kan niet met de ODT spec, aangezien die de syntax van formules niet specificeerd Als ik dat op basis van de OpenXML spec wil doen gaat dat echter prima.

Lastig kiezen

Om dit probleem te verhelpen is er OpenFormula.

OOXML kampt met dezelfde tekortkomingen:

The format specification references external formats which are not part of the Ecma standard, and therefore not covered by covenant not to sue: For example book 4 section 6.4.3.1 Clipboard format types.[29]

Bron

Uiteraard kun je dat niet met ODT, ODT is daar namelijk ook helemaal niet voor bedoeld. Voor spreadsheets hebben we ODS. ODT is bedoeld voor tekstdocumenten en daarin vindt je niet zo gauw formules zoals je die in spreadsheets wel vindt.

@hAl: Leuke manier om er omheen te praten, maar het probleem is niet de externe formaten die je kunt embedden, maar de externe formaten waar de standaard naar refereert. Als OOXML expliciet naar een extern formaat refereert, dan moet je dit formaat wel ook implementeren om OOXML volledig te implementeren. Om deze reden moet iedereen die OOXML volledig wil implementeren ook WMF ondersteunen, een formaat dat alleen op Windows ondersteund wordt.

Als OOXML expliciet naar een extern formaat refereert, dan moet je dit formaat wel ook implementeren om OOXML volledig te implementeren.

OOXML refereeert naar externe formaten bij de typebeschrijving van externe embedded plaatjes object. Je kunt daar bijvoorbeeld Windows meta files embedden of picture formaten. Het formaat wordt dus gerefereerd als een formaattype dat geembed kan worden evenals plaatjesformaten. Het formaat wordt niet gerefereerd als een onderdeel van het doucment maar juist expliciet als een extern objecttype.

Grappig genoeg daarintegen wordt in Opendocument bijvoorbeeld java als een intern object gedefinieerd. ODF heeft aparte embed-objecten voor externe fileformaten en een daarnaast een afzonderlijke functie java-object. Dus als je ODF wilt implementenren moet je ook geheel Java meenemen want dat zijn native objecten in ODF. Kadootje van Sun !!

OOXML kampt met dezelfde tekortkomingen:
The format specification references external formats which are not part of the Ecma standard,

Je kunt in ODF precies dezelfde externe formaten embedden als in OOXML dus dat is niet een relvant bezwaar tegen OOXML. Embedded external formats kunnen logischerwijs geen deel uitmaken van de standaard. Het in pure nonsense om te stellen dat dat een tekortkoming is van OOXML.

er is opzich niks mis mee met meerdere 'standaarden', uiteindelijk bepaald de markt (consument) wel wat het beste is

Jij werkt kennelijk nooit met meerdere standaarden die hetzelfde beschrijven, daar is in de praktijk een heleboel mis mee! Ga maar na hoeveel problemen de naast elkaar bestaande Amerikaanse / SI eenheden geven (lb per square inch enz.). Het is de reden dat een van de marskarretjes van meer dan 1 miljard crashte. Converteren kost iedere dag geld, moeite, en levert fouten op. Het links rijden en rechts rijden in verschillende landen kost ook alleen geld en moeite, en levert zelfs gevaar op. DVD+ en - zijn voor zover ik het weet geen ISO, maar industriestandaarden door de industrie zelf gemaakt. Het idee van een standaard is niet dat er dertig verschillende van zijn. Immers, als OpenXML standaard wordt, wat let Haancom uit Zuid Korea en EIOffice uit China, en mogelijk vele anderen dan om hun eigen formaat niet te laten standaardiseren in een ISO?

i.p.v. die tekortkomingen aan te passen en een betere ODF standaard creëren, zitten ze zich bezig te houden met dit soort pesterijen.

Pardon? Microsoft had de kans een betere ODF standaard te creeren, en heeft die kans nog steeds, als lid van het OASIS commitee met volledige inspraak. In plaats daarvan hebben ze ODF lopen te pesten door met hun eigen standaard te komen en deze er via misbruik van hun monopoliepositie doorheen te drukken.
Kijk naar UOF: Noch ODF noch OpenXML losten de problemen van Aziatische talen op. Daarom werdt UOF opgericht. In plaats van deze te laten concurreren met ODF (pesterijen a la Microsoft) wordt eraan gewerkt deze te integreren met ODF.

Microsoft had de kans een betere ODF standaard te creeren, en heeft die kans nog steeds, als lid van het OASIS commitee met volledige inspraak

Microsft is niet gevraagd bij de oprichting van een technisch committe voor het creeren van een standaard voor een open office formaat. (toch vreemd om de marktleider in dat stadium te negeren terwijl die al enkel jaren bezig was met een XML formaat)
Pas toende standaard al vrijwel was gedefinieerd op basis van OpenOffice functionaliteit is MS gevraag om het formaat te steunen voor ISO certificatie en deel te nemen aan de ontwikkeling.
Toen waren echter mogelijkheden om comaptibel te te zijn met de bestaande miljarden Office documenten niet meer aanwezig en was het ook te laat om nog in hun Office 2007 pakket op te nemen. Ofwel een onmogelijkheid voor MS.

Het lijkt me sterk dat Open Office XML (zoals OpenDocument in het begin genoemd werd, ziet iemand een zekere gelijkenis?) te laat kwam om meegenomen te worden in Office 2007, aangezien op de OASIS mailing lists te zien is dat de ontwikkeling hiervan in 2002 gestart werd.

Teruggaand naar de ISO-standaardisering van OOXML, waar deze discussie om draait: De deadline van de applicatie van 1 bedrijf is natuurlijk een bijzonder slecht argument om een eigen ISO-standaard te rechtvaardigen.

Compatibiliteit met bestaande Office-documenten is overigens ook met ODF mogelijk, mits je bereid bent de standaard uit te breiden aangezien ODF inderdaad niet alle functionaliteit die mogelijk is in bestaande Office-documenten specificeert. Zoals ik in een andere post ook al aangaf zou het uitbreiden van ODF voor deze functionaliteit echter absoluut de voorkeur hebben boven de complete heruitvinding van het wiel dat OOXML is.

Bij de ontwikkeling in 2002 was Microsoft niet betrokken

Het technisch committe heette toe ook nog anders. Je kunt dat nog zien in die oude notulen.
Toen probeerde ze een standaard Open Office format te ontwikkelen en ze begonnen ook vanaf dag 1 met het bestaande OpenOffice formaat. Er was toe nog geen sprake van Opendocument of ISO standaardisering en ook geen sprake van betrokkenheid van Microsoft of enige wens daartoe.

Pas een paar jaar later zijn ze het opendocument gaan noemen om de associatie met OpenOffice kwijt te raken.

Hier staat anders dat ene Oliver Bell van Microsoft Corp. in maart 2001 al betrokken was bij de oprichting van het OASIS committee om te komen tot een "standard for the structured interchange of data among
hardware, software, and service providers who engage in any aspect of
providing election or voter services to public or private organizations"

Als ze daarna de boot hebben gemist is dat een resultaat van hun eigen laksheid en onwil. Overigens, sinds ze er wel bij betrokken waren, heb ik vernomen dat ze, zelfs toen ze (eindelijk) wel eens een keer de kans hadden, niet één keer zijn komen opdagen en schitterden door afwezigdheid, onder het excuus dat ze 'te laat gevraagd waren'. In werkelijkheid waren ze waarschijnlijk al aan het nadenken over hun eigen concurrende standaard. Als ze als industrieleider namelijk, ook al was het laat in het proces, opmerkingen hadden gemaakt dat ze aanpassingen wensten, was daar zeker naar geluisterd.

En kom aub. niet met linkjes naar wikipedia en dan roepen dat andere websites partijdig zijn, het is bekend dat je veel van die wikipedia artikelen (deels) zelf geschreven hebt, en nogal wat mensen twijfelen aan jouw eigen NPOV.

@hal:

wikipedia worden namelijk ook wel eens edits gemaakt waar meerdere kanten van een argument worden getoond

Weet ik. Microsoft betaalt daarvoor, wat op zich niet verkeerd is; het draagt bij aan in het totaal een NPOV. Maar de persoonlijke aanval op andere sites geeft aan dat je zelf geen NPOV hebt. Ik hoop overigens nog steeds dat Microsoft aan je denkt met kerstmis, want ik vind dat je zeer puik werk aflevert, en er enorm veel moeite in steekt en heel erg kundig bent (in tegenstelling tot mijzelf).
P.S. Jammer dat Raul niet meer op tweakers is trouwens, doe hem de groeten als je hem ziet, en zeg dat ik hem erg mis (wie anders reageert er om vier uur s'nachts namens z'n werknemer om mijn reacties recht te zetten?). De man kan me nog veel leren.

Micrsoft is wel lid van OASIS maar dan ivm met de standaardisatie van SOAP en webservices waarin MS een vooraanstaande rol in standaardisatie heeft.
Dat wil nog niet zeggen dat er geen andere projecten georganiseerd worden binnen oasis waar MS niet in zit.

Opendocument is ontstaan uit de ontwikkeling van een standaard Open Office format een project opgestart door Sun en OOo.
Je kunt rustig de OASIS website de notulen nagaan dat er toen nog geen sprake was van een ISO standaard en dat MS niet betrokken was en ook in dat stadium niet gevraagd is voor dat project.

En kom aub. niet met linkjes naar wikipedia en dan roepen dat andere websites partijdig zijn, het is bekend dat je veel van die wikipedia artikelen (deels) zelf geschreven hebt, en nogal wat mensen twijfelen aan jouw eigen NPOV

Ach nee, persoonlijke aanvallen. Wat vind ik dat nou vervelend...
Leuk dat je wikipedia leest maar je verwijst wel naar een stukje dat niet gaat over het schrijven van tekst maar het verplaatsen van tekst binnen een artikel. Dat gaat over artikelstijl en niet over NPOV.
En het pro-ooxml stukje dat ik citeerde van wikipedia staat grappig genoeg precies in hetzelfde artikel als het pro-odf stukje van Groklaw waar ik op reageerde (origineel van de Opendocument fellowship) en dat er ook met precies dezelfde edit op is gekomen. Op wikipedia worden namelijk ook wel eens edits gemaakt waar meerdere kanten van een argument worden getoond. Als ik dat erop gezet zou hebben dan zou ik daar nu heel tevreden mee zijn...
NPOV is waarschijnlijk erg voor een heethoofd als jij wat moeilijk te vatten.

goed punt kidde.
Wat M$ flikte doen ze voortdurend.
Met letterlijk alles wat een grote userbase heeft/standaard is hebben ze een eigen variant die incompatible is.
meest recent naast ClosedXML zijn de pdf variant en een rss implementatie.
Het wordt denk ik tijd om dit bedrijf met aan de kant een grote bijdrage aan groei, gestop wordt in het tegen houden van vooruitgang.
Zolang bedrijven Open Standaarden gebruiken moeten ze uiteindelijk een keer mee of worden ze uitgescheten.
Als het aan mij ligt het laatste.

<i>Er is al aangetoont dat de ODF standaard vele tekortkomingen heef</i>

Welke dan? Volgens mij valt dat namelijk wel mee. Dat je het misschien niet eens bent met de filosofie erachter (flexibiliteit, extendibility) kan zijn. Echter dat is wel een methodologische discussie.

@Ron.IT

JPEG had ook technische tekortkomingen (geen transparantie), dus nu ondersteunen de meeste grafische applicaties PNG.

Dat ben ik niet met je eens. JPEG is heel wat anders qua techniek dan PNG. Bij JPEG treed er verlies cq vervorming op. Dat is bij PNG niet het geval. JPEG heeft ook een andre functie als PNG, JPEG is bedoeld voor foto's, PNG voor plaatjes / illustraties. JPEG heeft dan ook geen transparatie, omdat je dat bij een foto niet nodig hebt
PNG is eigelijk een verbetering van het GIF formaat, GIF heeft namelijk een aanta beperkingen. Het kan maar 256 Kleuren in 1 plaatje gebruiken, en kan maar een soort transparatie aan. PNG daar integen maakt gebruik van 24bit kleuren, en een 8bit alpha kanaal (dat is voor transparantie) de vergelijk met GIF was beter geweest (vind ik).

Er is al aangetoont dat de ODF standaard vele tekortkomingen heeft, maar i.p.v. die tekortkomingen aan te passen en een betere ODF standaard creëren, zitten ze zich bezig te houden met dit soort pesterijen.

Het klopt dat ODF tekortkomingen heeft, maar daar wordt volop aan gewerkt hoor. ODF 1.1 is pas door OASIS goedgekeurd en lost eerder genoemde accessibility-problemen en enkele andere kleine problemen op. ODF 1.2 is momenteel volop in ontwikkeling en daarin zal ook OpenFormula, voor het formuleren van spreadsheet-formules, opgenomen zijn.

En OpenXML is ook niet optimaal, maar er is opzich niks mis mee met meerdere 'standaarden', uiteindelijk bepaald de markt (consument) wel wat het beste is.

Er is wel iets mis met meerdere standaarden. Namelijk dubbel werk om te implementeren en extra kosten en dataverlies door al dan niet volledige conversies.

[...], toch gaat OpenXML er komen, standaard of niet, en er zijn al documenten die niet juist vertaald kunnen worden naar ODF toe, simpelweg omdat de ODF standaard hier geen ruimte/specificaties voor heeft.

Dit is niet correct. ODF is niet voor niets gebaseerd op XML, waarbij de X voor eXtensible staat. Als je functionaliteit van ODF verlangt die ODF niet gespecificeerd heeft, dan biedt ODF juist expliciet de ruimte om de standaard uit te breiden. OpenOffice.org doet dit, en Microsoft kan en mag dat ook doen. De meeste ODF-proponenten zijn er dan ook voorstander van om de goede punten van OOXML in ODF op te nemen, zolang dit dan wel weer goed gedocumenteerd en gestandaardiseerd wordt. Vanuit dat licht is er dus helemaal geen noodzaak om met OOXML het hele wiel opnieuw uit te vinden, en is het dus ook overbodig en verwarrend om hiervoor een complete tweede standaard te accepteren.

En OpenXML is ook niet optimaal, maar er is opzich niks mis mee met meerdere 'standaarden', uiteindelijk bepaald de markt (consument) wel wat het beste is.

Om even met het laatste deel van je zin te beginnen, de markt bepaald niet per definitie welke het beste is - alleen welke uiteindelijk het meest gebruikt wordt en dat is een groot verschil!

De pijnpunten van de OpenXML standaard zijn vanuit het ISO (en de aangesloten instituten) gezien echter nog al fors:

• Veel verwijzingen naar interne Microsoft kennis - iets wat het genereren van Open XML documenten door derden eigenlijk onmogelijk maakt en uitlezen wordt al helemaal onmogelijk
• Bestaande ISO standaarden worden niet hergebruikt, in plaats hiervan wordt er eigenlijk altijd naar een MS standaard verwezen
• Niet echt een probleem voor het ISO maar wel voor de programmeur: Gebruik van binair gebaseerde formaten binnen de OpenXML specificatie waardoor XSLT processing van het document niet goed mogelijk is.

Ik vraag me dus serieus af waarom je dit terechte bezwaar van de BSI afdoet als een pesterijtje. En het BSI is echt niet de enige organisatie die tegen is, ook het Nederlandse NEN heeft serieuze bezwaren.

Bestaande ISO standaarden worden niet hergebruikt, in plaats hiervan wordt er eigenlijk altijd naar een MS standaard verwezen

OOXML gebruikt meer ISO standaarden dan ODF.
ODF gebruikt voornamelijk w3c recomendations en RFC's.

Niet echt een probleem voor het ISO maar wel voor de programmeur: Gebruik van binair gebaseerde formaten binnen de OpenXML specificatie waardoor XSLT processing van het document niet goed mogelijk

OOXML bevat alleen enkel binaire bitmasks voor legacy compatibiliteit. Wel lelijk maar die zijn voor een ontwikkelaar natuurlijk heel simpel eenvoudig in te bouwen hoewel de meeste implementaties die niet eens zullen hoeven ondersteunen. Binaire bestandsformaten maken verder geen deel uit van OOXML net zomin als ODF. Een referentie aan een extern formaat betekent dat je het verplicht bent te ondersteunen. Ook ODF ondersteunt object linking en OLE linking van in principe alle mogelijke fileformaten.

OOXML gebruikt meer ISO standaarden dan ODF.
ODF gebruikt voornamelijk w3c recomendations en RFC's.

Ik zal echt niet ontkennen dat ODF veel bestaande W3C standaarden hergebruikt, maar waarom zou je het wil steeds opnieuw uitvinden als er al een goede open standaard aanwezig is (ik denk aan SVG,MathML en XLink)???

Kun je dan ook een concreet voorbeeld geven waar OpenXML wel ISO-standaarden gebruikt en ODF niet. Zo wordt AFAIK voor het vastleggen van de taal in OpenXML naar IBM/MS codepages verwezen terwijl ODF hier de ISO-codering gebruik, als ik het mis heb mag je me overigens corrigeren hoor

OOXML bevat alleen enkel binaire bitmasks voor legacy compatibiliteit. Wel lelijk maar die zijn voor een ontwikkelaar natuurlijk heel simpel eenvoudig in te bouwen hoewel de meeste implementaties die niet eens zullen hoeven ondersteunen. [...] Ook ODF ondersteunt object linking en OLE linking van in principe alle mogelijke fileformaten.

Als de 'MyOffice' suite niet in staat is om OpenXML in het geheel goed te lezen dan krijgt 'MyOffice' daar de schuld van niet het feit dat MSOffice toevallig een binairy opgenomen heeft als onderdeel van de XML, niet als losstaand bestand - dus moet men al deze zaken wel implementeren.

Hetzelfde geldt voor alle 'like office'2000,like word 6' en dergelijke definities - volgens zeggen bestaat OpenXML uit 6000 pagina's en dan kunnen ze nog niet eens een selfcontaining document maken? (al dan niet met verwijzingen naar andere [i]publieke[/i] documentatie.

OOXML gebruikt meer ISO standaarden dan ODF.
ODF gebruikt voornamelijk w3c recomendations en RFC's.

Belangrijker is misschien om te vermelden met hoeveel ISO-standaarden OOXML conflicten heeft. Zo definieert OOXML hoe datums gerepresenteerd moeten worden en vereist daarbij zelfs dat het jaar 1900 incorrect als schrikkeljaar wordt geimplementeerd omdat dat een bug in Excel nu eenmaal ook zo gedaan wordt. Dat terwijl er allang een goede ISO-standaard bestaat voor hoe we datums volgens de Gregoriaanse kalender opslaan. Bijzonder slordig voor een "standaard" dat een stempel van ISO hoopt te krijgen.
Meer voorbeelden zijn te vinden op GrokDoc.net

OOXML bevat alleen enkel binaire bitmasks voor legacy compatibiliteit.

Waarom zou een nieuw formaat bitmasks voor legacy compatibiliteit moeten gebruiken? Het is een nieuw formaat en voor compatibiliteit met legacy applicaties moeten er sowieso conversies plaatsvinden. Waarom zijn dit soort problemen dan niet opgelost in de converters in plaats van alle oude bugs en limitaties van de oude applicaties mee te nemen naar het nieuwe formaat?

Wel lelijk maar die zijn voor een ontwikkelaar natuurlijk heel simpel eenvoudig in te bouwen hoewel de meeste implementaties die niet eens zullen hoeven ondersteunen.

Ter info: Voor iemand die in XSLT programmeert is dit niet simpel in te bouwen. Het voordeel van XSLT is dat het zelf ook in XML beschreven is. Om bitmasks te ondersteunen moet er alsnog terug worden gevallen op een andere programmeertaal, en is XSLT-conversie dus in het geheel niet mogelijk.

@hAl: Die methode had ik nog niet aan gedacht, nee. Je hebt gelijk dat het dus mogelijk is om bitmasks te gebruiken in XSLT. Alleen als ik zie hoe omslachtig het is ben ik blij dat ik dat nog nooit heb hoeven toepassen, en dat bevestigt eigenlijk alleen dat bitmasks in een XML-formaat een slecht idee zijn. De efficientie, het enige potentiele voordeel van bitmasks, gaat volledig verloren als je zulke algoritmes nodig hebt om na te gaan welke bits er gezet zijn.

Het lijkt me zeker iets wat of in toekomstige versie wordt mogelijk kan worden afgeschaft of vervangen door een xml alternatief.
Het is echter nauwelijk een reden om een standaard op af te wijzen.

Ter info: Voor iemand die in XSLT programmeert is dit niet simpel in te bouwen. Het voordeel van XSLT is dat het zelf ook in XML beschreven is. Om bitmasks te ondersteunen moet er alsnog terug worden gevallen op een andere programmeertaal, en is XSLT-conversie dus in het geheel niet mogelijk

.

Haal je deze FUD van Grokdoc of weet je echt wel waar je het over hebt ???
Ik zal je verwijzen naar de reactie van Rick Jeliffe een XML expert die al jaren meewerkt aan w3c standaards, een bekende column over XML publiceert en bovendien lid is van het ISO committee dat zich bezig houd met bijvoorbeeld OOXML:
http://www.grokdoc.net/in...icant_validation_problems

Precies. Iedereen kent .doc! Top formaat. We bouwen er gewoon wat xml omheen en voila een openstandaard.

Grappig. +1 van mij.

hmm vergeten op "beoordeling insturen" te drukken..

Dus de bestandsformaten lijken op elkaar, net als bij DVD+ en DVD-?

Er is al aangetoont dat de ODF standaard vele tekortkomingen heeft, maar i.p.v. die tekortkomingen aan te passen en een betere ODF standaard creëren, zitten ze zich bezig te houden met dit soort pesterijen.

Ik neem aan dat je bedoelt dat de Britse standaardinstituut pest. Maar je zou het net zo goed over MS kunnen zeggen: waarom moest MS nou weer zo nodig een eigen standaard ontwikkelen, terwijl ze die energie ook hadden kunnen steken in het meehelpen aan ODF?

Hier ben ik wel blij mee.

Microsoft heeft heel snel iets in elkaar proberen te zetten. ODF heeft een procedure van 2 jaar van feedback doorlopen. Microsoft probeert hetzelfde in 1 maand em hoopt dat niemand oplet. Dan was het formaat namelijk erdoor gekomen.

Als je de bezwaren tegen OpenXML doorleest merk je dat het een memory dump van Office's interne data structuren is. Inclusief verwijzingen naar "paragraaf spacing als word 7" "bullets als word 6" "emuleer datum bugs van excel" en "border-style: apple". Maar wat zijn precies "bullets als word 6"? Hoe werkt die paragraaf spacing? Waarom kun je niet gewoon een willekeurige afbeelding als border-style gebruiken? En hoe breed is die border-style dan?

Ofwel ook met de specificatie kun je niet een 2e applicatie maken die de tekst hetzelfde kan renderen. Ook bevat OpenXML verwijzingen naar WMF en OLE, die alleen onder Windows kunnen werken. Het is dus niet zo open als Microsoft wil laten geloven.

ODF heeft inderdaad nog niet uitgewerkte delen, zoals de formules. OpenXML zit echter vol onuitgewerkte delen. Als deze standaard doorgekomen was, had de innovatie van de industrie eerder tegengehouden dan verbeterd.

Kijk en vergelijk:

OpenDocument:

<text:p text:style-name="Standard">
This is a <text:span text:style-name="T1"> very basic </text:span> document
<text:span text:style-name="T2"> with some </text:span> formatting,
and a <text:a xlink:type="simple" xlink:href="http://example.com"> hyperlink </text:a>
</text:p>

OpenXML:

<w:p>
<w:r> <w:t>This is a </w:t> </w:r> <w:r> <w:rPr> <w:b /> </w:rPr> <w:t>very basic</w:t> </w:r> <w:r> <w:t> document </w:t> </w:r> <w:r> <w:rPr> <w:i /> </w:rPr> <w:t>with some</w:t> </w:r> <w:r> <w:t> formatting, and a </w:t> </w:r> <w:hyperlink w:rel="rId4" w:history="1"> <w:r> <w:rPr> <w:rStyle w:val="Hyperlink" /> </w:rPr> <w:t>hyperlink</w:t>
</w:r> </w:hyperlink>

bron

Maar wat zijn precies "bullets als word 6"? Hoe werkt die paragraaf spacing?

Dat kan je voorlopig alleen dmv reverse engineering van de desbetreffende producten achterhalen, en dat is tegen de EULA van desbetreffende producten (denk DCMA et all.) Een conforme implementatie zou dus mogelijk ook illegaal zijn.

Microsoft probeert hetzelfde in 1 maand.

Wat een onzin. MS is al sinds medio 2005 bezig met Open XML.

Niet het uitdenken, maar de specificatie door de ISO heen loodsen.. Bij de ISO is er een fast-track proces, en dat duurt 1 maand. Als niemand oplet was het er dan zeer gemakkelijk doorheen gekomen .

@hAl: oke.. idd 9.5 maand totaal, en uit dezelfde bron:

Review period by JTC 1 National Bodies: 30 days

Daarna moet de fabrikant het commentaar verwerken en volgt daarna de volgende ronde.

De fastrack procedure van OOXML duurt minimaal 9,5 maand en zeker geen 1 maand.
Dat is pure FUD. Gewoon verzonnen.

De door OOXML gevolgde procedure is zelfs langer dan de door ODF gevolgde PAS procedure die minimaal 7 maanden duurt.
Het ISO standaardisatie traject van OOXML is dus langer dan dat van ODF !!!

Reactie op edit YaBB

@hAl: oke.. idd 9.5 maand totaal, en uit dezelfde bron: Review period by JTC 1 National Bodies: 30 days Daarna moet de fabrikant het commentaar verwerken en volgt daarna de volgende ronde.

en die volgende ronde is precies waar ODF is begonnen !!!I Die heeft dus juist die maand overgeslagen.
In de vervolgperiode kunnen de nationale organisaties dus nog zeker 6 maanden de specs beoordelen en erover te stemmen.

Net dat verschil dat ODF iets is waar al veel langer vanuit de industrie commentaar op geleverd is, terwijl de specs van OOXML slechts zeer kort voor de indiening bij het ISO af was. Mensen hebben veel langer naar het .ODF-formaat kunnen kijken en er bezwaren tegen kunnen formuleren dan tegen OOXML, wat ook nog eens veel groter is (9000 pagina's ofzo, geloof ik): per pagina heeft de OOXML-specificatie met ruime afstand de minste tijd per pagina van alle ISO-standaarden.

Kijk en vergelijk:

altijd leuk om suggestief bij groklaw te plukken een groot OOXML tegenstander.
ander voorbeeld:

OOXML:

<row><c><v>1</v></c><c><v>2</v></c><c><v>3</v></c></row>
<row><c><v>4</v></c><c><v>5</v></c><c><v>6</v></c></row>

ODF

<table:table-row table:style-name="ro1">
<table:table-cell office:value-type="float" office:value="1">
<text:p>1</text:p>
</table:table-cell>
<table:table-cell office:value-type="float" office:value="2">
<text:p>2</text:p>
</table:table-cell>
<table:table-cell office:value-type="float" office:value="3">
<text:p>3</text:p>
</table:table-cell>
</table:table-row>
<table:table-row table:style-name="ro1">
<table:table-cell office:value-type="float" office:value="4">
<text:p>4</text:p>
</table:table-cell>
<table:table-cell office:value-type="float" office:value="5">
<text:p>5</text:p>
</table:table-cell>
<table:table-cell office:value-type="float" office:value="6">
<text:p>6</text:p>
</table:table-cell>
</table:table-row>

Bron is wikipedia.

ODF vanuit OpenOffice:

<config:config-item config:name="DoNotJustifyLinesWithManualBreak" config:type="boolean">false</config:config-item>

In de spec over 'DoNotJustifyBlaat', helemaal noppes.

Valt me op dat er met FUD wordt geschoten, mensen herhalen alleen maar oud commentaar wat al lang is weerlegt. Het enige wat echt jammer is aan open XML is de datum ellende vanwege Excel. Grappig is wel dat dit is geintroduceerd in Excel om compatible te zijn met Lotus 1-2-3, lol.

Dit is gewoon een ordinair machts spelletje.

ODF is niet zomaar een open standaard... het is (voor velen) een anti-MS standaard. Hetgeen mooi tegelijkertijd ingezet kan worden tezamen met de anti-MS lobby bij de (europese) overheden.

Die anti-MS sentimenten kun je niet zo makkelijk meer voeden, wanneer MS ook een ISO standaard heeft, die eigenlijk nog beter is ook.

Ik denk ook dat de BSI voornamelijk met een vertragings actie bezig is.

Ik denk ook dat de BSI voornamelijk met een vertragings actie bezig is.

Niet alleen de BSI.. Er hebben 19 laden tegengestemd. Dat is meer dan het aantal wat normaal gesproken de moeite neemt om op te komen dagen.

Well the results are in, and an unprecedented nineteen countries have responded during the contradictions phase (..) This may not only be the largest number of countries that have ever submitted contradictions in the ISO/IEC process, but nineteen responses is greater than the total number of national bodies that often bother to vote on a proposed standard at all.

bron: http://www.kdedevelopers.org/node/2668
http://www.consortiuminfo...p?story=20070206145620473

Waar zie jij dat 19 landen hebben tegengestemd? Er staat alleen dat er 19 landen hun beoordeling ingestuurd hebben (19 submissions).

most or all lodging formal contradictions with Joint Technical Committee 1

Goede opmerking. Er staat: 19 stemden, de meesten of allemaal (echter, niet NL) maakten formele bezwaren (stemden tegen).

Het is inderdaad een ordinair machtsspelletje van Microsoft. Zij zitten immers al tijden in de commissie die volledig verantwoordelijk is voor ODF en heeft hier absoluut niets mee gedaan. In korte tijd nadat het ODF vrijgegeven was kwamen zij zelf met een eigen standaard op de proppen waarbij ze als hoofdreden aanvoerden dat ODF niet backwards compatible zou zijn met Microsoft's oude binary formaten. Waarom heeft Microsoft niet gewoon gebruik gemaakt van haar positie en zodoende het e.e.a. bijgedragen aan de ontwikkeling van ODF waardoor deze wel backwards compatible was met Microsoft's spul? Die hele zetel in die commissie is er om in de gaten te houden wat de concurrentie doet, niet bepaald om ODF tot een succes te maken.

Microsoft heeft kansen zat gehad waarvan ze totaal geen enkel gebruik hebben en als je daarbij optelt dat ze kort nadat ODF werd vrijgegeven met een eigen XML based standaard op de proppen kwam waarvan ze graag willen dat die dezelfde weg volgt als ODF dan kun je niet anders concluderen dat Microsoft een machtsspelletje probeert te spelen. Als je nadenkt over waarom ze ODF als ISO standaard willen hebben dan zie je dat men ineens niet meer beperkt is tot het gebruik van een bepaald softwarepakket. Dat zou tot verlies van het marktaandeel van Microsoft Office kunnen leiden en dan is het begrijpelijk dat Microsoft hier wat aan wil doen. Ze hebben genoeg motieven om vooral niet mee te doen aan ODF i.t.t. motieven om juist wel mee te doen aan ODF.

Ik vind het wel mooi dat MS eist dat ODF backwards compatible moet zijn met office, wat geeft ze het recht??
Het is dan ook geen open standaard meer te noemen. Immers andere mogen het dan niet implementeren.. (aangezien de offce formaten zelf nog steeds closed zijn)

OpenXML blijft voor mij nog steeds MS office in XML. Niks open.
Het idee van een standaard is dat andere partijen er ook iets mee kunnen (niet alleen office, windows van MS)

Tja, als ik het volgende lees, zijn er, ondanks het machtspelletje, zeer goede redenen OpenXML in de huidige vorm geen ISO norm toe te kennen:

OOXML bevat daarnaast een aantal tegenstrijdigheden, zo stellen bezwaarmakers. Zo houdt OOXML zich niet aan de ISO-norm voor tijdsaanduidingen, de ISO-norm voor namen en talen, normen voor cryptografie en het conflicteert met de recente ISO-norm voor documenten, Open Document Format, ODF. (Gijs Hillenius)

bron

Vooral de laatste is aardig: Microsoft had ook van ODF kunnen uitgaan, en zelf een standaard maken die een aanvulling in plaats van volledige vervanging van ODF is. Zo hadden ze bijvoorbeeld een aanvulling kunnen maken voor de spreadsheet spec die ODF momenteel (zo goed als) ontbeert.

ODF is niet zomaar een open standaard... het is (voor velen) een anti-MS standaard. Hetgeen mooi tegelijkertijd ingezet kan worden tezamen met de anti-MS lobby bij de (europese) overheden.

Wat let MS om ODF als default bestandsformaat in Office te gaan gebruiken? Wat let MS de energie die in OpenXML wordt gestoken in ODF te steken? Helemaal niets. ODF is geen anti-MS standaard, ODF is een echte open standaard.

Er is maar 1 reden voor MS om een eigen standaard te ontwikkelen en dat is vendor-lock-in. MS wil koste wat het kost voorkomen dan Office compatible wordt met andere Office-pakketten, omdat ze dat weten dat er een hoop gebruikers weg zullen lopen.

In feite zegt MS gewoon: wij weten ook wel dat de kwaliteit van MS Office de gebruikers niet vast zal houden, dus we zorgen op een andere manier dat de gebruikers niet weg kunnen.

Zet nou die Pro-MS pet eens af en vraag je af wat voor andere redenen MS heeft om niet ODF als standaardbestandsformaat toe te passen.

ODF is minder goed? Non-argument, want dan hadden ze hun energie maar moeten steken in het helpen van verbeteren van ODF, ipv het ontwikkelen van een eigen standaard.

Amen!

OpenXML word toch de standaart. MS pusht het met office 2007 keihard de markt in. Zolang office 2007 by default geen odf ondersteund, word openxml de standaard. Hoe graag ik ook zou zien dat dit anders was.
Maargoed, we hebben het nu over het Britse standaardeninstituut. Bestaat hier ook een nederlandse versie van?

Yep. En ook die wordt het vuur aan de schenen gelegd door de filantropische wereldverbeteraars uit Redmond: http://automatiseringgids...euwsbericht.jsp?di=305075

In totaal 19 landen, waaronder Nederland, heeft wel commentaar geleverd op het fast-track proces. Of Nederland alleen daadwerkelijk een contradiction hebben ingediend staat niet expliciet vermeld:
ConsortiumInfo.org

In het AG bericht van hierboven staat dat Nederland heeft onthouden nadat MS op bezoek was geweest... Stelletje laffe hazen dat wij zijn.

Het gaat ook volgens mij niet eens om het goedkeuren alleen of het versneld kan worden goedgekeurd. M.a.w. een "nee" nu is alleen maar dat MS het er niet doorheen kan drukken en een langere procedure gaat volgen. Wat helemaal niet zo'n slecht idee is gezien de commotie en belanggen omtrent.

* cybero blij dat andere landen wel ballen hebben.

Trouwens MS standaard komt met een "covenant not to sue" met andere woorden de standaard is van MS je mag het proberen te reverse engineren (maar verwacht geen hulp van MS) en gebruiken zonder dat je office hebt.

link naar wikipedia waar dit instaat.

@hAl: Je doet alsof je goed op de hoogte bent. Dan ken je zeker ook deze link wel, waarin wordt uitgelegd waarom de covenant not to sue juridisch gezien geen enkele waarde heeft?
EOOXML objections

Tjezus, wat een flauwekul schrijven de mensen hier. De standaard is van Ecma [...] en [..] (er) wordt (door MS) beloofd dat je hun patenten zonder meer mag gebruiken voor het implementeren van de Ecma standaard.

Aleen ga je niet in op het feit dat je aan reverse-engineering moet doen om OpenXML volledige volgens de spec te moeten implementeren.

En volgens Amerikaans recht is reverse engineering verboden, waardoor het dus onmogelijk is om zonder verder hulp van Microsoft de OpenXML standaard te implementeren.

@hAl: Je doet alsof je goed op de hoogte bent. Dan ken je zeker ook deze link wel, waarin wordt uitgelegd waarom de covenant not to sue juridisch gezien geen enkele waarde heeft?
EOOXML objections

Ja die link ken ik heel goed. Een site gevuld met veelal disinformatie. Zowel onvolledige als onjuiste informatie.
Ik heb op een deel ervan gereageerd op de bijbehorende discussiepagina.
Echter op deze pagina worden alleen voor OOOXML negatieve berichten doorgegeven en als je daar nuance in aanbrengt wordt dat genegeerd !!

Ten aanzien van de commentaren over het CNS en de licencing van OOXML in de objections heb ik bijvoorbeeld de volgende zaken opgemerkt:
http://www.grokdoc.net/in...OXML_objections#Licensing
http://www.grokdoc.net/in...s_in_Licensing_discussion
http://www.grokdoc.net/in...L_objections#Patent_claim

Daarnaast heb ik nog opgemerkt:
http://www.grokdoc.net/in..._639_issue_is_not_correct
http://www.grokdoc.net/in...tafile.29_issue._More_FUD
http://www.grokdoc.net/in...st_examples_.3F.3F.3Fhttp://www.grokdoc.net/index.php/Talk:EOOXML_objections#OOXML_does_use_standard_dates.
http://www.grokdoc.net/in...WIPpy_objection_.3F.3F.3F

Zoals je kunt constateren is met GEEN enkel van deze opmerkingen iets door de Grokdoc beheerders gedaan. Ze noem het wel een wiki maar de openheid van een wiki is er ver te zoeken.
Zet een pagina neer met overdrijvingen, leugens en zaken uit context en je ziet hoeveel mensen daar klakkeloos achteraan lopen en een dergelijke site gaan zitten citeren terwijl ze nauwelijks inhoudelijk een idee hebben van de inhoud en de feitelijke juistheid van deze info of hoe relvant deze info is voor ISO standaardisatie.

Duizenden mensen hebben zonder meer deze site naar hun landelijk vertegenwoordigers in de ISO gestuurd zonder te beseffen dat war er op staat op zijn minst heel dubieus is en over het algemeen niet feitelijk correct. Een FUD pagina noem ik het.

Aleen ga je niet in op het feit dat je aan reverse-engineering moet doen om OpenXML volledige volgens de spec te moeten implementeren

Je hoeft geen reverse engineering the doen. Ik geef toch aan dat de spec volledig is gepubliceerd en gratis bij Ecma te downloaden.

Waarom zou je reverse enginerren wat al voor je is opgeschreven !!!!

edit:
Aanvullend. Het enige wat niet staat beschreven zijn depriciated features die bepaalde rendering bugs uit oude office versies beschrijven. Die depreciated feutures zijn expliciet juist niet bedoeld om geimplementeerd te worden maar bedoeld om gebruikers te informeren dat de originele rendering kan afwiijken ten opzich van de huidige rendering en waarom. De originele redendering kan je allean met de origniele applicatie terugkrijgen. Zelfs met MS Office 2007 kun je niet al die features meer renderen

Het enige wat niet staat beschreven zijn depriciated features die bepaalde rendering bugs uit oude office versies beschrijven.

Dus het feit dat 1900 volgens MSO een schrikkeljaar is dat mogen we negeren en we mogen 1900 beschouwen als een normaal jaar?

Dus het feit dat 1900 volgens MSO een schrikkeljaar is dat mogen we negeren en we mogen 1900 beschouwen als een normaal jaar?

Dat staat uitstekend en duidelijk in de specs beschreven (en is simpel te implementeren) en hoeft dus niet gereverseengineered te worden of zoiets.

En het is eigenlijk een origineel idee van Lotus-1-2-3 en niet van MSO.

Trouwens MS standaard komt met een "covenant not to sue" met andere woorden de standaard is van MS je mag het proberen te reverse engineren (maar verwacht geen hulp van MS) en gebruiken zonder dat je office hebt

Tjezus, wat een flauwekul schrijven de mensen hier. De standaard is van Ecma en de volledige beschrijvening kun je daar gratis downloaden.
http://www.ecma-internati...ns/standards/Ecma-376.htm
Het covenant not to sue heeft betrekking op methoden en technieken waarop MS patent heeft en waarin wordt beloofd dat je die patenten zonder meer mag gebruiken voor het implementeren van de Ecma standaard.

Zodra overheden (en eventueel bedrijven) gaan vragen om open ISO standaarden in hun officetoepassingen zal ook Microsoft aan deze vraag moeten voldoen.

Als MS dat niet wil of kan dan zullen de overheden vanzelf overgaan op alternatieven zoals OpenOffice.org, IBM's officesuite (die ze dan echt wel zullen hebben - aangezien ze al veel hebben als onderdeel van hun Lotus suite) of zelfs Corel's WordPerfect.

Natuurlijk zullen met name bedrijven, die nu ook niet echt pushen voor open office standaarden, en consumenten (die ook tevreden zijn met MSO) Microsoft's office blijven gebruiken.

Hoe graag ik ook wil geloven dat de overheden MS de rug toe keren, ik zie het niet gebeuren.

Overheden zijn heel goed in aan de ene kant formeel protesteren en aan de andere kant het tegenover gestelde doen. ( gigantisch veel in MS inkopen, Economische keuze, functionele keuzes, ik weet het niet.) Zo werkt het vaak wel.

Voorbeeld: op een gegeven moment werd IE officieel als onveilig bestempeld en de voorkeur gegeven aan firefox browser door mijn onderwijsinstelling. Echter voor sommige sites binnen die onderwijsinstelling heb je IE nog steeds nodig...

Nog een aanvulling op het wel/niet open genoeg zijn van het OpenXML formaat:
Zodra een officeformaat er voor kan zorgen dat er naast een (ex)monopolist ook een andere office veel gebruikt zal gaan worden (en er ook andere kleinere office suites (qua) marktaandeel een bestaansrechten hebben) is het formaat ook open genoeg.

Kijk maar eens naar HTML/CSS/JavaScript - MS heeft hier jaren een marktaandeel van bijna 95% weten vast te houden, inmiddels is hun marktaandeel gezakt tot onder de 75 tot 80 procent en wordt de andere plm 25 procent verdeelte onder Firefox, Safari en Opera.

De huidige definitie van OpenXML maakt een vergelijkbare verdeling op officegebied niet mogelijk en is dus overduidelijk niet open!

N.B. Nu weet ik ook wel dat ODF dit ook niet mogelijk maakt, maar dat komt omdat MS geen gebruik (wil) maken van ODF - bij browsers was men verplicht om HTML te gebruiken vanwege het Netscape monopolie, maar het gevolg is wel dat door deze open standaard uiteindelijk anderen weer een succesvolle aanslag hebben kunnen doen op MSIE's monopolie...

Een van de reden die daarvoor aangehaald werden, was dat er geen nood is om twee verschillende standaarden in het leven te roepen. Het Open Document Format is door de ISO al goedgekeurd als standaard en dat volstaat volgens aanhangers van dit formaat.

Eerst plof! Er is al een formaat (ons) dus mogen er geen andere zijn. Beetje vreemde reden.

Nee, er mogen geen twee standaarden zijn die hetzelfde beschrijven. Net zoals het SI en imperiale standaarden allebei meetkundige eenheden beschrijven, en dit in de praktijk erg lastig is, vanwege het steeds moeten converteren.

Echter, het mag prima zo zijn dat een standaard conische pennen (DIN 1), en de volgende cilindrische pennen beschrijft; zolang ze maar niet conflicteren met bestaande ISOnormen. OpenXML conflicteert met de ISO (DIN in het voorbeeld) standaard die ODF beschrijft.

De goede weg zou dus zijn, in het OASIS committee (waar Microsoft lid van is) te vragen ODF zo te wijzigen dat aan haar wensen tegemoet gekomen worden en in ODF verwerkt worden, of een standaard te maken als aanvulling op ODF.

Eerst plof! Er is al een standaard die dit beschrijft (onze)... Ze hebben dus eigenlijk patent op die standaard

Volgens mij begrijp je niet helemaal wat het doel is van een standaard. ISO heeft als doel het vereenvoudigen van de internationale handel door het definieren van standaarden. Standaarden vereenvoudigen de handel doordat dubbel werk voor implementaties voorkomen wordt en doordat je minder conversie-problemen hebt. Door nog een "standaard" te accepteren voor iets waar je al een standaard voor hebt, ga je rechtsstreeks in tegen het doel waarom je in de eerste plaats een standaard gemaakt hebt.

Ik ben voor het standariseren van ASCII als nieuw document formaat Als ik bovendien ODF als versie nummer beschouw dan is PDF de opvolger..

afgekeerd = afgekeurd?