Welkom in de 'Nieuwe Wereld van Documenten'

Iso

Gepubliceerd: Woensdag 2 april 2008

Microsoft heeft zich met de ontwikkeling en standaardisatie van Open XML uitgesproken vóór interoperabiliteit, vóór open standaarden en vóór keuze, stelt Hans Bos.

Toon volledig artikel

Bolleke op Woensdag 2 April 2008 17:45

image zomerhack badge 3

Nou, zal ik het spits dan maar afbijten? :)

Ik kan natuurlijk 1000 dingen hierover zeggen, maar ik wil me in eerste instantie even controleren op het volgende citaat, omdat dat de kern van je betoog lijkt te zijn:
Het verplicht 'opleggen' van één standaard leidt tot beperkingen in ontwikkelingen van mogelijkheden en toepassingen die niet waren voorzien door die ene standaard. Geheel in lijn met wat in andere gebieden binnen de IT wordt gedaan (grafische formaten: JPEG, TIFF en meer, video: MPEG2 en H.264, programmeer talen: C++, Pascal, Basic) bestaan er meerdere standaarden prima naast elkaar. Dit ondersteunt de verschillen in wensen en eisen van gebruikers, ontwikkelaars en organisaties.
Wat staat hier nu eigenlijk?

"Het verplicht 'opleggen' van één standaard leidt tot beperkingen in ontwikkelingen van mogelijkheden en toepassingen die niet waren voorzien door die ene standaard."
Deze zin snap ik niet. Ten eerste kan die beperking er ook zijn met 1000 standaarden, vooropgesteld dat ze geen van allen precies de goede mogelijkheden bieden. Daarnaast kan een standaard gewoon uitgebreid worden als daar vraag naar is; voor HTML is men alweer met versie 5 bezig.

"Geheel in lijn met wat in andere gebieden binnen de IT wordt gedaan (grafische formaten: JPEG, TIFF en meer, video: MPEG2 en H.264, programmeer talen: C++, Pascal, Basic) bestaan er meerdere standaarden prima naast elkaar."
Los van het feit dat Pascal en Basic AFAIK geen "standaarden" zijn heb je het hier over een compleet andere situatie. Afbeeldings- en videoformaten hebben elk hun eigen sterktes en zwakheden, en de keuze is hierbij sterk afhankelijk van het beoogde doel. B.v. JPEG is erg geschikt voor foto's, terwijl GIF extreem sterk is met kleurvlakken (waar JPEG juist heel zwak is). Dit is omdat ze de data op een andere manier comprimeren, ik neem aan dat je dat weet(*).

Ook bij videoformaten zijn er keuzes tussen performance en kwaliteit te maken mbt de verschillende formaten. Dat de keuze voor een programmeertaal sterk van het beoogde doel afhangt (een 3D-shooter in Basic maken zou... interessant zijn) hoef ik hier neem ik aan niemand uit te leggen.

Office-documenten daarentegen bezitten een grote mate van uniformiteit in de verschillende Office-pakketten. Juist hier zou het dus nuttig zijn 1 standaard te hebben, aangezien gebruikers - zoals je zelf al aangeeft - ook een uniforme weergave verwachten. En terecht, IMO. Deze situatie is dus compleet anders dan de keuze voor PNG of TIFF bij een afbeelding. Dat is een technische overweging, terwijl gebruikers er bij Office-standaarden juist vanuit willen gaan dat hun data betrouwbaar opgeslagen is. Dat kan alleen met 1 standaard.

Als je mij een waslijst aan zaken kunt noemen die ODF niet ondersteunt en OOXML wel, inclusief duidelijke motivatie /waarom/ deze onmisbaar zijn voor MS Office en /waarom/ ODF kennelijk "by design" dit nooit zal kunnen ondersteunen (anders had MS immers wel met ODF mee kunnen doen en het uitbreiden), dan heb je een sterke zaak. Tot die tijd blijft er rond OOXML de zweem hangen dat het slechts bedoeld is om Microsoft een voordeel ten opzichte van haar concurrenten te geven, en daar zijn standaarden nou eenmaal niet voor bedoeld.

(*) opvallend: AFAIK is PNG de standaardste standaard onder de grafische formaten, en juist die noem je niet. Nou ja, IE ondersteunt het ook nog niet zo lang volledig natuurlijk...

  • 12 / 12

Hans Bos op Donderdag 3 April 2008 09:04

image

Los van het feit dat Pascal en Basic AFAIK geen "standaarden" zijn...
Pascal: ISO 7185:1990
Basic: ISO 10279:1991
en C++, C# en veel meer programmeertalen zijn ISO standaarden.

...heb je het hier over een compleet andere situatie.
Dat denk ik niet. Ook voor documenten is de situatie nu al zo dat er meerdere standaarden zijn die ieder een 'specialisatie' of doelstelling hebben. Wanneer je documenten bekijkt als eenvoudig wat "opmaak" (vet, schuin, onderstreept etc), dan kon dat inderdaad ook al met HTML (ISO 15445), maar documenten worden voor veel meer zaken gebruikt. Van eenvoudige briefjes, semantisch documenten, tot en met complete 'interfaces' naar bedrijfsinformatie. Open XML ondersteunt die breedte van inzet. Er zijn vele onderscheidende karakteristieken voor Open XML ten opzichte van DOC, ODF, PDF, UOF, CDF, HTML, SGML etc. De opmerking "Office-documenten daarentegen bezitten een grote mate van uniformiteit in de verschillende Office-pakketten" betreft alleen de basis functionaliteit van documenten.
De verschillen tussen ODF en Open XML waar je naar vraagt zijn de afgelopen tijd al uitgebreid en regelmatig besproken. Hier: www.openxmlcommunity.org vind je bijvoorbeeld al veel.

opvallend: AFAIK is PNG de standaardste standaard onder de grafische formaten, en juist die noem je niet.
JPEG: ISO 15444, TIFF: ISO 12634, PNG: ISO 15948 etc.

  • -2 / 6

Bolleke op Donderdag 3 April 2008 11:14

image zomerhack badge 3

Pascal: ISO 7185:1990
Basic: ISO 10279:1991
Ik zei dan ook "AFAIK". Maar bedankt voor de info, I stand corrected. Overigens verandert dat niks aan mijn argument: programmeertalen dienen compleet verschillende doelen, daarom is het niet vreemd - zelfs wenselijk - dat er meerdere van zijn. Ook is het uiteraard wenselijk dat een taal uniform gespecificeerd is zodat je hetzelfde programma op verschillende compilers/interpreters/platformen kun draaien.
Een lichte uitzondering kun je maken voor C#. Is het C++? Is het Java? Nee, het is C#, iets wat er ongeveer tussenin zit! Niet geheel toevallig ook van Microsoft. Zie je al een patroon? Ik wel...

Dat denk ik niet. Ook voor documenten is de situatie nu al zo dat er meerdere standaarden zijn die ieder een 'specialisatie' of doelstelling hebben.
Vandaar nogmaals mijn vraag: wat is de compleet afwijkende specialisatie/doelstelling van OOXML ivm ODF die de eerstgenoemde nodig maakte? Supporters van OOXML roepen om het hardst dat ODF structureel niet voldeed, maar waarin hem dat precies zit lijkt niemand te kunnen uitleggen...

Wanneer je documenten bekijkt als eenvoudig wat "opmaak" (vet, schuin, onderstreept etc), dan kon dat inderdaad ook al met HTML (ISO 15445), maar documenten worden voor veel meer zaken gebruikt. Van eenvoudige briefjes, semantisch documenten, tot en met complete 'interfaces' naar bedrijfsinformatie.
<sarcasme>Ik heb net om te testen voor het eerst van mijn leven een tekstdocument gemaakt, en ik moet je gelijk geven: je kunt er meer mee dan typen!</sarcasme>
Maar alle gekheid op een stokje, HTML heeft hier niks mee van doen en dat weet je zelf natuurlijk ook wel. "Kijk naar [vul willekeurige standaard in], daar kun je ook geen office-documenten mee maken!!!" Nee, en OOXML is niet geschikt om internetsites in te schrijven.

("Interfaces naar bedrijsinformatie" is trouwens IMO iets waar je Office-documenten zeker /niet/ voor moet gebruiken. Dat veel prutsers het desondanks toch doen doet daar niks aan af. Maar dit terzijde)

Open XML ondersteunt die breedte van inzet. Er zijn vele onderscheidende karakteristieken voor Open XML ten opzichte van DOC, ODF, PDF, UOF, CDF, HTML, SGML etc. De opmerking "Office-documenten daarentegen bezitten een grote mate van uniformiteit in de verschillende Office-pakketten" betreft alleen de basis functionaliteit van documenten.
Nogmaals, kom dan eens met een lijst van dingen die OOXML kan welke ODF niet kan en nooit zal kunnen? Dat argument is nu zo vaak herhaald, zo'n lijst moet toch gewoon voorhanden zijn, zeker binnen de gelederen van MS?

De verschillen tussen ODF en Open XML waar je naar vraagt zijn de afgelopen tijd al uitgebreid en regelmatig besproken. Hier: www.openxmlcommunity.org vind je bijvoorbeeld al veel.
Gek, ik heb er al ugh keer om gevraagd in de diverse discussies, maar niemand heeft er een kunnen noemen. Wel heeft alberthalbaseline een aantal vermeende fouten in ODF voorgedragen, maar die bleken meestal aan zijn eigen gebrekkige kennis van de materie te liggen. Daarnaast gaat het er niet om of ODF wel of niet perfect is: MS heeft bij hoog en bij laag beweerd dat ODF /inherent/ ongeschikt was voor ze. Tot ik daarvoor een gedegen onderbouwing heb gezien kan ik niet anders dan deze stelling scharen in hetzelfde rijtje als "Windows /kan/ niet functioneren zonder IE": een aantoonbare leugen.

opvallend: AFAIK is PNG de standaardste standaard onder de grafische formaten, en juist die noem je niet.
JPEG: ISO 15444, TIFF: ISO 12634, PNG: ISO 15948 etc.
Ik zei niet "de enige", ik zei "de standaardste". PNG is altijd compleet patentenvrij geweest, in tegenstelling tot in elk geval JPEG en GIF (TIFF weet ik niet uit m'n hoofd) en was specifiek bedoeld als open en vrij implementeerbare tegenhanger van de overige genoemde formaten (in een tijd dat b.v. GIF leed onder patentenkwesties).

  • 9 / 9

baseline op Vrijdag 4 April 2008 08:12

image

Een belangrijke doelstelling van Office Open XML die niet door open document wordt ondersteund is het bieden van compatibilitteit met de miljarden bestaande office documenten.
Je kunt oude office documenten met een zeer hoge mate van betrouwbaarheid converteren naar OOXML.
Ook biedt Office Open XML in essentie dezelfde features als de meeste Office programmatuur al ondersteunt(zoals spreadsheet formules) waardoor je bijvoorbeeld implementaties heel makkelijk kan aanpassen om het niew formaat te gebruiken.
Zo kan bijvoorbeeld een open source spreadsheet als Gnumeric heel eenvoudig Office Open XML ondersteuning aanbieden met veel hergebruik aan code voor bestaande Office programmatuur.
Bij OpenDocument is dat heel anders. Zo gooit bijvoorbeeld de OpenOffice calc spreadsheet applicatie bijvoorbeeld nog steeds complexere formattering van OpenDocument files weg omdat het die formattering niet ondersteunt. Je ziet eigenlijk dat OpenDocument nog geen hele goede ondersteuning kent omdat het niet aansluit op hoe bestaande office applicaties functioneren.

  • -4 / 6

toiletpaper op Vrijdag 4 April 2008 08:31

image

Dat doel ahd ook anders bereikt kunnen worden wanneer MS in een vroeg stadium was ingestapt in ODF. Jet feit dat het dat niet wilde proberen illustreert dat het geen prijs stelt op een eenduidige standaard.

Maar dit is al duizend keer gezegd, en wat jij zegt ook.

Dus, zullen we nu allemaal ophouden met papagaaien van onszelf opf anderen, en iets nieuws zeggen, want ik kan me amper voorstellend at iemand dit slaapverwekkend geneuzel nog kan appreciëren.

Iets nieuws, het falen van ISO, Mark Shuttleworth (Ubuntu) zegt in ZDNet:
The International Standards Organization (ISO) did not carry out its responsibility, he claimed. “It’s sad that the ISO was not willing to admit that its process was failing horribly,” he said, noting that Microsoft intensely lobbied many countries that traditionally have not participated in ISO and stacked technical committees with Microsoft employees, solution providers and resellers sympathetic to OOXML. “When you have a process built on trust and when that trust is abused, [ISO] should halt the process.” Shuttleworth

Ook Microsfot erkent dat politieke overwegingen belangrijker waren dan technische overwegingen, Andrew Brust, an RDN contributor, Microsoft regional director and chief of new technology:
"I think the worst you can say about that effort was that it was necessary to make the vote fair, and it was unfortunate that the OOXML standard could not be judged exclusively on its technical merits," Brust said. "Were it judged that way, without the politics, I think it would have won approval [in the first round of voting], and done so with much less rancor."

Ze leggen het accent anders maar erkennen beiden dat ISO niet meer werkt, zoals het ooit gewert heeft. Wat zegt dit over de standaard waarbij dit falen van ISO aan het ligt is gekomen?

Ook nog andere feiten illustreren dit, bijvoorbeeld dat de Chinese stem evenzwaar weegt als de stem uit Malta. Hoelang zullen grote landen/economieen zoals Cina en India (beiden tegenstemmers) dit pikken?

Niet lang, dat is zeker, over een paar jaar wordt OOXML aand e kant geschoven door UOF, waarin Sun participeert

Dag Microosft, de slag gewonnen, maar de oorlog gaan jullie zeker verliezen.

Juist, rommel!!

  • 6 / 6

toiletpaper op Vrijdag 4 April 2008 08:32

image

excus voor de vele taalfouten (haast, haast.....(

  • 3 / 5

Hans Bos op Vrijdag 4 April 2008 09:10

image

Dus, zullen we nu allemaal ophouden met papagaaien van onszelf opf anderen, en iets nieuws zeggen, want ik kan me amper voorstellend at iemand dit slaapverwekkend geneuzel nog kan appreciëren.

Dus ik reageer alleen even op een "meta" ding.

Ook nog andere feiten illustreren dit, bijvoorbeeld dat de Chinese stem evenzwaar weegt als de stem uit Malta. Hoelang zullen grote landen/economieen zoals Cina en India (beiden tegenstemmers) dit pikken?

En dan nog even voor de zekerheid, want wellicht begrijp je dit eigenlijk ook wel. Namelijk dat ISO standaarden niemand tot iets verplicht. Een land, zoals je China noemt als voorbeeld, is nu niet ineens verplicht iets te doen met OpenXML of welke andere ISO standaard dan ook. Een ISO standaard borgt met name de internationale participatie en de duurzaamheid, toegangkelijkheid etc van de specificatie.
Als China liever UOF wil gebruiken. Prima.
Als ze dat ook tot een ISO standaard wil maken. Prima.
Het lijkt me overigens juist prima dat een klein land (zoals Nederland) dezelfde rechten en positie heeft bij standaardisatie als een groot land (bijvoorbeeld de US). Het is geen verkiezing om macht of iets dergelijks.

  • -3 / 3

toiletpaper op Vrijdag 4 April 2008 09:14

image

Wellicht begrijp je ook wel wanneer ISO dat wil zijn waarvoor eht acroniem staat dat het onverteerbaar is dat de vertegenwoordiging van 100.000 mensen 1,1 miljard mensen kan overrulen.

  • 3 / 3

baseline op Vrijdag 4 April 2008 10:50

image

De landen die gekozen hebben voor Office Open XML produceren wel veel meer Office documenten dan de landen die hebben tegengestemd. Je kan daarin goed zien dat landen waar de behoefte aan een formaat met hoge compatibiliteit blijkbaar Office Open XML belangrijker vinden.

Het is trouwens opvallen hoe jij 1 kleine voor en 1 grote tegenstemmer qua stemming matched. Zeker aangezien er een verhouding van 6 tegen 1 was in voor en tegenstemmers Misschien moet je je afvragen of ene tegenstem van bijvoorbeeld Iran belangrijker is dan de 6 voor stemmen van de Verenigde Staten, Groot Brittanie, Japan, Argentinie, Duitsland en Egypte.

  • -3 / 5

toiletpaper op Vrijdag 4 April 2008 11:38

image

Het is trouwens opvallen hoe jij 1 kleine voor en 1 grote tegenstemmer qua stemming matched.
het is een sprekend voorbeeld. laten we niet vergeten dat de vertegenwoordigingen van de helft vand e wereldbevolking tegen was. Dus breed gedragen wordt OOXML echt neit, en als ik moet gokken of Chinese documenten of Maltese docuemtnen belangrijker zijn in Nederland, dan kies ik voor Chinese. Zo zal bijna iedereen in Nederland denken.

Het Chinese UOF wordt belangrijker dan het Maltese OOXML, om het zo maar eens uit te drukken.

  • 3 / 3

toiletpaper op Vrijdag 4 April 2008 11:40

image

Hetzelfde geldt voor India, Brazilië, de grootste landen ter wereld.

  • 3 / 3

toiletpaper op Vrijdag 4 April 2008 11:41

image

en nu mag je het laatste woord even hebben, want ik besteed veel te veel tijd aan deze nutteloze onzin. Doe jij dat maar op kosten van ons, belastingbetalers (zoals je zelf altijd zegt).

  • 3 / 3

baseline op Vrijdag 4 April 2008 16:43

image

Dat zeg ik zeker niet. Wat een bespottelijk opmerking
Als ik tijd besteed om hier te reageren moet ik daarvoor gewoon langer doorwerken.

  • -2 / 2

toiletpaper op Vrijdag 4 April 2008 22:33

image

Dus al die duizenden reacties, op fora wereldwijd, die enorme hoeveelheid fora gelezen, die honderden wikipedia-edits, dat doe je allemaal onbetaald, in je eigen tijd? Het moet je, zowat, je volledige vrije tijd kosten.

Dringt zich bij mij de vraag op of jij misschien een missionaris bent van een nieuw geloof: Microsoft?

Want van een normale hobby voor naast je werk is dan geen sprake meer.

  • 3 / 3

baseline op Zaterdag 5 April 2008 08:41

image

Ik weet niet of het je opvalt maar de meeste van mijn reacties plaats ik hier en daar zie ik nog meer reacties van jou dan van mij. Jij plaats hier alleen op webwereld ook duizenden reacties. Laat staan wat je op andere plakken nog becommnetarieert.

  • -3 / 3

toiletpaper op Zondag 6 April 2008 00:57

image

Ik zei al, ik doe het alleen op Webwereld, jij wereldwijd, ik kom jou overal tegen waar ik lees. Dat is gewoon een feit. Maar moet je alweer naar anderen wijzen, wordt wel een beetje typisch, die reactie.
En zelfs al zou dat anders zijn, dan blijft het feit dat jij duizenden comments hebt gegeven afgelopen maanden, en aangezien je zelf zegt een baan te hebben hiernaast, kan het alleen maar zijn dat je maandenlang je volledige vrije tijd gegeven hebt aan het verdedigen van OOXML.

Ik noem dit fanatisme, of iets dergelijks. Fundamentalisme kan ook. Van een objectieve houding is in elk geval, naar mijn mening, geen sprake.

Dat is wat mij opvalt.

En wat mij betreft, ik besteed alleen tijd aan de OOXML discussie op webwereld, en de meeste tijd aan jou, omdat jij het meest vastbesloten bent je eeuwige argumenten te herhalen.

  • 3 / 3

thieu op Vrijdag 4 April 2008 22:15

image

Je kan daarin goed zien dat landen waar de behoefte aan een formaat met hoge compatibiliteit blijkbaar Office Open XML belangrijker vinden. Goh, dat heb je leuk gevonden. Het zou natuurlijk ook kunnen dat in de tegenstemmende landen de invloed van MS minder groot is...

  • 3 / 3

toiletpaper op Vrijdag 4 April 2008 09:17

image

Het is geen verkiezing om macht of iets dergelijks.
Ik geloof niet dat jij zo naïef bent om dit te geloven, maar eht zegt wel iets over hoe jij over je lezers denkt.
Microsoft heeft de ISO-erkenning door puur machtsvertoon gewonnen, het is bijna kinderachtig om dit te ontkennen.

Hoor ik daar iemand IBM roepen? Of Sun? Ik moet me vergist hebben, ik dacht dat ik het hoorde. In elk geval zou dat een extra aanwijzing zijn geweest dat het om macht gaat, pure macht, economische macht, marktaandeel.

  • 5 / 7

baseline op Vrijdag 4 April 2008 10:25

image

Dat doel ahd ook anders bereikt kunnen worden wanneer MS in een vroeg stadium was ingestapt in ODF

Dat had misschien een optie geweest als men in OASIS
* Niet voor de oprichting van de TC al gekozen had om een document formaat voor Open Office te ontwikkelen maar een document voormaat voor Office applicaties. (het was tot 2004 dus ook de Open Office TC geleid door Sun).
* Niet voor de oprichting van de TC gekozen had om direct al uit te gaan van het bestaande Open Office document formaat
* Niet voor de oprichting in de TC al een voorstel had voor deelenemers waar geen Micrsoft of anderszins in MS Office formaten geinsteresseerde partij bijzat. (ofwel met had MS gewoon genegeerd bij de oprichting van de TC)
* Niet bij de oprichtingsbijeenkomst van de TC al meteen had besloten om compatibiliteit met MS documenten niet als een doel te zien.

Ofwel er is nooit serieus sprake geweest van het betrekken van Microsoft bij de Open Office TC waar ODF is ontwikkeld (toen nog het OpenOffice XML formaat)

  • -2 / 6

toiletpaper op Vrijdag 4 April 2008 10:48

image

Je ehbt gelijk, er zijn keuzen gemaakt zonder dat Microsoft daarop invloed had. Dit had anders kunen zijn als Mcirosoft zijn gewicht in de schaal had gelgd, maar dat weigerde het.

Microsoft wilde in geen geval samen met IBM en Sun een Office-standaard bouwen. Dit is het Bill Gates doctrine dat hij frank en vrij voor de rechtbank verklaarde in 2002, de relatie is tot een andere situatie, maar het doctrine is helder tussen de regels door te lezen. het geeft tussen de regels exact weer waarom Microsoft niet in Oasis samen met IBM en Sun aan een XML Office standaard wilde werken.
Er is geen mens die serieus gelooft dat IBM en Sun er in konden slagen om Microsfot's invloed te weren binnen Oasis, als Microsoft ahd willen meedoen. het verleden heeft ook vaak anders uitgewezen. Hans Bos refereerde er al aan, Microsoft heeft al vaker binnen Oasis an een standaard meegewerkt.

Dit soort Calimero argumenten die er nu weer aankomen zijn werkelijk erg vermoeiend en doorzichtig.

"Splendid isolation" is de gebruikelijke policy van MS, tientallen jaren lang, en ook nu. En daarom is ODF ontstaan zonder invloed van MS.

  • 6 / 6

baseline op Vrijdag 4 April 2008 10:55

image

Dit had anders kunen zijn als Mcirosoft zijn gewicht in de schaal had gelgd, maar dat weigerde het.

Je kunt niet weigeren wat je niet is gevraagd.

  • -3 / 5

toiletpaper op Vrijdag 4 April 2008 10:58

image

Je kunt jezelf aanbieden, anders zijn ze ook niet verlegen, maar nu gaan we het over communicaties hebben, wie heft wie en wanneer gebeld en wat gevraagd, en op welke toon, etc, en verdere onzin.

  • 1 / 1

baseline op Vrijdag 4 April 2008 15:18

image

Waarom zou MS zich aanbieden om een Open Office formaat te gaan ontwikkelen.

  • -4 / 4

toiletpaper op Vrijdag 4 April 2008 15:25

image

MS had zich kunnen aanbieden om een OFfice-standaard te ontwikkelen, net zoals het toen in zijn eentje ging doen, als het interoperabiliteit had nagestreefd had het het beter samen kunne doen, maar dat was tegen het Gates paradigma

Waarom geef je dat niet gewoon toe? het wordt werkelijk kinderachtig, al die uitvluchten, het lijkt wel of je voor MS werkt, want die zitten er ook vol mee. In plaats van interoperabiliteit uitvluchten op Calimero-niveau

  • 4 / 4

toiletpaper op Vrijdag 4 April 2008 11:01

image

De intentie van Gates was vlak voor de eerste ODF TC op een rechtszaak duidelijk verwoord, zie een beetje hieronder, in een volgende reactie.

Ik heb geen zin om allerlei kinderachtige ontkenningen te moeten bestrijden. ik heb ander werk te doen.

  • 1 / 1

toiletpaper op Vrijdag 4 April 2008 10:56

image

Het volledige citaat uit de beschrijving van de rechtszaak (november 2002, vlak voor de standaardisatie van Office-documenten een aanvang nam (Wikipedia zegt: The first official ODF-TC meeting to discuss the standard was December 16, 2002)):

The company purposefully designed Microsoft Office so that its Web page output would render correctly only in Internet Explorer (IE). Allowing Office documents to be rendered very well by other people's browsers is one of the most destructive things we could do to the company

Bill Gates III, Star witness for the Defense

  • 2 / 2

Bolleke op Vrijdag 4 April 2008 11:12

image zomerhack badge 3

Een belangrijke doelstelling van Office Open XML die niet door open document wordt ondersteund is het bieden van compatibilitteit met de miljarden bestaande office documenten.
Ik vraag het nog maar een keer: noem dan eens wat onoverkomelijke zaken die niet in ODF zitten, die deze compatibiliteit onmogelijk maken? Want als ik een oud .DOC bestandje opsla als ODT en het daarna opnieuw open ziet het er prima hetzelfde uit.

Je hamert op compatibiliteit zonder aan te geven waar de eventuele knelpunten dan zouden moeten zitten.

  • 5 / 5

Manuzhai op Woensdag 2 April 2008 18:01

image

Beste Hans,

Ik heb in beginsel niets tegen het bestaan van meerdere standaarden die tegen elkaar moeten opboksen. Maar ik vind het werkelijk waar onbegrijpelijk dat je je niet kapot schaamt voor de manier waarop deze certificatie tot stand is gekomen.

Ten eerste de standaard zelf: deze zit nu nog vol fouten. Het is schaamtelijk dat niet de tijd is genomen om het aantal fouten terug te brengen alvorens deze bij het ECMA te fasttracken. Het is nog veel schaamtelijker dat bij het ISO voor een Fast Track-aanpak is gekozen, waarbij duizenden meer en minder breed gedragen bezwaren onbesproken zijn gebleven.

Verder is de manier waarop vele ontwikkelingslanden (met name degene die bekend staan als corrupt) zich "ineens" hebben aangemeld als P-lid van de JCT1 een schande (en dan hebben we het nog niet eens over de wijze waarop als deze thans niet-functionerende landen niet stemmen op andere voorstellen die aan de commissies worden voorgelegd, en de gevolgen die dit heeft voor andere standaarden). De manier waarop in Noorwegen de mening van 80% van de landelijke commissie is genegeerd? Schandelijk.

Ik hoop dat er de komende twee maanden bezwaar wordt gemaakt tegen deze standaard. Ik hoop dat Neelie Kroes nog een paar miljard euro onttrekt aan Microsoft. Ik hoop dat OOXML spoedig ten onder gaat aan het succes van de overduidelijk technisch superieure ODF-standaard.

Ik ben een groot fan van sommige Microsoft-software. Ik gebruik dagelijks Windows (XP). Jarenlang was Internet Explorer verreweg de beste browser. Maar sommige tactieken zijn ontoelaatbaar. Het corrumperen van het ISO hoort daarbij. De dubieuze manier waarop sommige landen hebben meegewerkt aan het realiseren van OOXML hoort daar ook bij.

Ga je schamen, en rap wat.

  • 11 / 13

Hans Bos op Donderdag 3 April 2008 09:22

image

Maar ik vind het werkelijk waar onbegrijpelijk dat je je niet kapot schaamt voor de manier waarop deze certificatie tot stand is gekomen.

Er zijn een aantal situaties in het proces waar sommige mensen of bedrijven zich inderdaad voor zouden moeten schamen. Gelukkig ligt dat allemaal buiten het ISO proces en heeft het vooral te maken met de manier waarop er gecommuniceerd werd. Opruiende taal, ongefundeerde beweringen en beschuldigingen, onnodige polarisatie dat soort werk.

De associatie die jij probeert op te roepen met landen die nu participeren in het proces, onderschrijf ik absoluut niet. Het proces heeft veel aandacht opgeroepen. Dat geeft vervolgens aanleiding tot meer participatie. Lijkt me een logisch gevolg. Ook in Nederland is de commissie (weer) opgericht naar aanleiding van Open XML.

Je haalt Noorwegen weer eens aan, maar misschien moet je je dan eerst verdiepen in de situatie aldaar. De Noorse organisatie had al geruime tijd terug besloten (en bekend gemaakt) dat de beslissing niet op basis van alleen de commissie zou worden genomen, maar dat er meer faktoren zouden meespelen. Vervolgens publiceert een teleurgestelde commissievoorzitter een verhaal en "hopla" weer een nieuwe scene in het theater...
Zie hier voor meer achtergrond: blogs.msdn.com/...table-path.aspx

Ik hoop dat OOXML spoedig ten onder gaat aan het succes van de overduidelijk technisch superieure ODF-standaard.

Kijk, dat is een mening die je kunt hebben en waar je op een positieve manier aan kunt werken: voorzover ik heb begrepen komt ODF 1.2 later dit kalenderjaar in de versnelde ISO standaardisatie procedure tussen OASIS en ISO.

  • -4 / 6

toiletpaper op Donderdag 3 April 2008 20:03

image

Kijk, dat is een mening die je kunt hebben en waar je op een positieve manier aan kunt werken: voorzover ik heb begrepen komt ODF 1.2 later dit kalenderjaar in de versnelde ISO standaardisatie procedure tussen OASIS en ISO.
Gaat het hier ook om 6000 nieuwe pagina's?

  • 3 / 5

Bolleke op Donderdag 3 April 2008 20:36

image zomerhack badge 3

Gaat het hier ook om 6000 nieuwe pagina's?
Ik denk dat in die ontbrekende 6000 pagina's dan alle functionaliteit staat die ODF by design nooit kan ondersteunen. Ofzo. Ik weet het anders ook niet ;-)

  • 5 / 7

FreeDisk op Woensdag 2 April 2008 20:08

image

Tijd om het volgende filmpje te gaan verspreiden:

http://nl.youtube.com/watch?v=XXDRWzA4TGk

Microsoft heeft met Internet Explorer al bewezen niet verantwoordelijk om te kunnen gaan met standaarden. Stop OOXML.

  • 4 / 8

Hans Bos op Donderdag 3 April 2008 09:35

image

Creatief werk.
Bekijk deze video's ook eens:
www.youtube.com/openxml

  • -5 / 5

thieu op Vrijdag 4 April 2008 22:30

image

Haalt het niet bij het filmpje dat FreeDisk aangaf hoor. Dát is tenminste een filmje dat met passie en overtuiging een BOODSCHAP brengt. Het filmpje waar jij aan refereert is een ontzettende saaie reclameboodschap van een medewerker van MS. Na ongeveer een minuut sliep ik zowat. :-)

  • 3 / 3

Obituary op Woensdag 2 April 2008 22:16

image

Het belangrijkste dat opvalt aan dit verhaal van Microsoft Nederland is hoe weinig ze snappen waarom IT professionals steeds meer hameren op interoperabiliteit en open standaarden. De achterliggende reden is echt niet dat ze een warm gevoel krijgen van een ISO standaard nummer. IT professionals willen keuze hebben, en om keuze te hebben moet er volledige interoperabiliteit tussen producten zijn. Keuze voor een office applicatie maakt wellicht ook keuze voor een onderliggend platform mogelijk. Twee keuzes die momenteel nauwelijks realistisch zijn.

Als Microsoft mee was gaan werken aan ODF dan was er nu wellicht een keur aan office applicaties die allemaal nu of in de nabije toekomst echt interoperabel waren. En misschien dat er inderdaad ODF 2.0 nodig was om alle gewenste functionaliteit op te nemen. Maar Microsoft is niet mee gaan werken aan ODF maar heeft OOXML geintroduceerd. Wat is de keuze die IT professionals krijgen met OOXML? Kunnen we nu wel kiezen welk office pakket we gebruiken, en op welk platform dat we dat willen gebruiken? Het lijkt erop van niet, want de standaard is slecht te implementeren voor andere partijen, en zelfs Microsoft's eigen office 2007 wijkt af van de standaard.

Dus Microsoft, gefeliciteerd met de iso standaard, maar ik geloof niet dat de IT professionals er blij van worden. Want met ooxml is de keus Microsoft office 2007 op windows of Microsoft office 2007 op de mac. En zoveel keus hadden we vroeger ook al.

  • 9 / 9

Hans Bos op Donderdag 3 April 2008 09:31

image

Bezoek deze site eens:
www.openxmlcomm...plications.aspx
een aantal ontwikkelaars, platformen, producten en projecten staan daar genoemd die reeds in meer of mindere mate Open XML geimplementeerd hebben.

Keuze voor een office applicatie maakt wellicht ook keuze voor een onderliggend platform mogelijk. Twee keuzes die momenteel nauwelijks realistisch zijn.
Dat is raar. Bedoel je dat je niet kunt kiezen tussen Open Office of Microsoft Office? Kan ik ergens mee helpen?

...en zelfs Microsoft's eigen office 2007 wijkt af van de standaard.Versies van standaarden zijn altijd in beweging. Welke versie van ODF heeft Open Office geimplementeerd? Microsoft heeft aangegeven dat ze de ISO versie van Open XML zal implementeren in haar producten. Dat kan uiteraard pas na goedkeuring. Dus tot die tijd is het de Ecma Office Open XML specificatie van Open XML waar de markt alvast mee aan de slag is gegaan.

  • -2 / 4

Obituary op Donderdag 3 April 2008 12:46

image

Dat is raar. Bedoel je dat je niet kunt kiezen tussen Open Office of Microsoft Office? Kan ik ergens mee helpen?

Hans je maakt jezelf nu belachelijk. Je kunt nu een heel erg naief persoon gaan uithangen, maar je weet net zo goed als elke andere IT professional dat je op dit moment als grote organisatie nauwelijks van Microsoft Office af kunt stappen vanwege de bestandsformaten. En dat gaat echt niet veranderen met OOXML. Dat lijstje software waarin OOXML geimplementeerd is is zodanig beperkt dat de toekomstige keuze Microsoft of Microsoft blijft. Jouw nieuwe wereld van documenten is oude wijn in nieuwe zakken.

  • 9 / 11

baseline op Vrijdag 4 April 2008 10:59

image

Dat lijstje software waarin OOXML geimplementeerd is is zodanig beperkt dat de toekomstige keuze Microsoft of Microsoft blijft

De lijst met OXML implementaties is al zodanig groot en groeiende dat misschien nu al maar zeker binnen een jaar er meer OOXML implementaties zijn dan ODF implementaties. En ook vollediger implementaties (niet moeilijk want van ODF zijn er na al die jaren nog steeds lang geen volledige implementaties).

  • -3 / 5

toiletpaper op Vrijdag 4 April 2008 11:05

image

Van OOXML ook niet, end at maakt niet uit, er zijn veel zinvolle standaarden die deels worden geimplementeerd. je gaat toch niet dat deel implementeren dat je neit ndoig hebt?

Al weer een punt waaruit blijkt dat jij eigenlijk weinig begrijpt van het aflopende betekenis van het document paradigma

Vraag het aan Hans Bos, die begrijpt het. Het gaat om informatie, neit om volledige implementaties, eht is geen wedstrijdje van nutteloze software.

Als ik als kantoormachine (business machine) uitsluitend teksten wil doorzoeken, waarom zou ik dan tekeningen moeten interpreteren?

Kom nou een smet een echt argument, of nog beter, laat maar zitten, dat gevit van jou is niet om aan te zien.

  • 1 / 5

toiletpaper op Vrijdag 4 April 2008 11:07

image

sorry, ik werd persoonlijk, ik liet me meeslepen.

  • 1 / 5

Anonymous Coward op Vrijdag 4 April 2008 13:12

image

!

  • -5 / 5

toiletpaper op Vrijdag 4 April 2008 13:22

image

!!!!

  • 0 / 6

toiletpaper op Vrijdag 4 April 2008 13:31

image

maar ik geef het toe, jij niet

  • 0 / 6

toiletpaper op Vrijdag 4 April 2008 13:50

image

Kom op SEDje, reageer eens, of laat je het alweer afweten als er een weerwoord komt? Want dat gebeurt best vaak, vandaar dat ik steeds minder tijd aan discussie met jou wil besteden

  • -1 / 5

Rijk op Woensdag 2 April 2008 23:58

image

Lees wat Tim Bray te zeggen heeft over OOXML. Ik kan wel proberen dat hier te herhalen, maar hopelijk kent iedere geinteresseerde wel genoeg Engels om dat stuk te lezen. Conclusie: het heeft voordelen dat Microsoft haar Office bestandsformaten heeft vastgelegd in een openbare spec, maar het geeft (om goede redenen) geen pas dit een ISO-standaard te maken.

  • 6 / 6

ArjenB op Zaterdag 5 April 2008 10:56

image

Geen tijd gehad om het eerder te lezen. Bray geeft argumenten voor en tegen, komt niet tot een definitief oordeel:

Well, my mind is still open. Locking Microsoft into a set of XML-based document-structure rules they have to play by (even if they wrote the rules), well, there’s probably an upside to that. But on the other hand, I dislike OOXML at an engineering level and I really dislike the cynical, abusive standards process it came with.

At the moment, it looks like we get the benefits (covenant not to sue, stable spec), without the downsides (Microsoft marketing club, rewarding ISO malfeasance) even if the ISO process fails.

What am I missing?

Verplichte kost. Lezen.

  • 2 / 2

Acarya op Donderdag 3 April 2008 12:58

image

Waarom staat dit Microsoft persbericht eigenlijk onder 'opinie?' Er staat alleen de gebruikelijke verzameling marketing-speak in, en het voegt niets toe aan wat we al wisten. Of het moest zijn dat meneer Durusau nu echt bij de kleine club hoort ;-)

  • 8 / 8

Duh op Donderdag 3 April 2008 15:00

image

Het spijt me, maar dit opiniestuk staat zo bol van typische Microsoft halve waarheden en verdraaingen dat het niet uitnodigt tot een serieuze dialoog.

Laat ik een voorbeeldje nemen:
Het verplicht 'opleggen' van één standaard leidt tot beperkingen

Niemand, maar dan ook helemaal niemand, heeft het ooit gehad over het 'verplicht opleggen van een standaard'. Hooguit kiest een overheid als de Nederlandse voor standaardisatie, maar dat is volkomen normaal binnen een organisatie. Zat bedrijven hebben gestandaardiseerd op MS Word, en dat is hun goed recht.

Hans Bos probeert hier op typische Microsoft wijze te suggereren dat MS een strijd voert tegen hele enge mensen die hele restrictieve regeltjes willen opleggen, om daarmee de aandacht af te leiden van de daadwerkelijke issues, en de aandacht te richten op niet-bestaande stromannen.

Zolang Microsoft op deze wijze wenst te communiceren hoeft het van mij niet. Meneer Bos moet eerst zelf maar eens de open brief van Patrick Durusau goed doorlezen.

Daarnaast kunnen we discussieren totdat we een ons wegen, feit blijft dat we nu met de standardisatie van OOXML nu de primeur hebben van een ISO-standaard die de facto maar door een bedrijf volledig kan worden geimplementeerd. En zelfs dat bedrijf implementeert de standaard zelf niet in hun producten. Alle intenties en samenzweringstheorieen terzijde, elke objectieve waarnemer kan concluderen dat dat een absurde situatie is die de geloofwaardigheid van de ISO volkomen ondermijnt. En er is weinig dat de indruk kan wegnemen dat dat ook precies het doel was van deze actie.

Tot de dag van vandaag wachten we nog steeds op het harde bewijs dat het Microsoft serieus is met interoperabiliteit en standaarden. Tot nu toe blijft het bij beloftes met vele addertjes onder het gras. Laat Microsoft eerst maar eens bewijzen dat het een serieuze dialoog waard is.

Microsoft is net een dief die wel zegt berouw te hebben, maar de gestolen goederen niet wil teruggeven voordat we 'm alles vergeven hebben en geloven dat 'ie een eerbaar burger is geworden. Zo werkt het niet.

  • 9 / 9

Anonymous Coward op Donderdag 3 April 2008 20:33

image

Beste Hans Bos:
Nu zal ik dus van de hele discussie in opbouw van formaten geen moer snappen, ik ben maar een "gebruiker".
1 Wat is bij MS de definitie van een document?
2 Wat is bij MS de definitie van "semantisch documenten, tot en met complete 'interfaces' naar bedrijfsinformatie." zoals bedoelt in OOXML

Ik wil de documenten en documentatie van en rond de communicatie met anderen kunnen lezen, geval 1 wat ik totaal niet wil is een complete database met berekeningen, macro's en aanverwante "onbegrijpelijke" rommel als 2. Als ik een offerte wil krijg ik een "document" elektronisch of niet, waar het resultaat in staat, niet de berekening, dit geld ook voor mijn hypotheek, verzekering, belasting aangifte en zo voort.

Als MS in Office dit zelf CS regelt en weer kan geven naja sho what, dit kan een bestand opleveren dat intern en naar andere filialen gebruikt kan worden (zoals photoshop, Acad, enzovoort) het product dat uitgespuwd wordt naar de printer of Email is vele malen eenvoudiger, voldoet ODF dan nog niet?

Wat heb ik aan een document waar ik hele complexe zaken kan regelen om te weten hoeveel belasting ik moet betalen? (terugkrijgen is een moeilijker voorbeeld :))
Wat moet ik met een briefje van mijn zwager van 10 regels met een kilo aan ongebruikte verwijzingen die het bestand alleen maar onnodig groot maakt?

  • 2 / 2

baseline op Vrijdag 4 April 2008 08:20

image

Het lijkt me een misvatting als je denkt dat ODF simpelere documenten oplevert. Zo kun je bijvoorbeeld in ODF files willekeurige spreadsheetformules gebruiken of een willekeurige macrotaal of willekeurige binaire inhoud.
ODF laat dat alemaal vrij en niet beschreven.
Momenteel werk ODF alleen enigzins omdat alle partijen de bewuste niet beschreven functionaliteit overnemen uit OpenOffice. Zodra een andere partij (bijvoorbeeld MS) ODF gaat gebruiken om andee functionaliteit in onder te brengen valt elke interoperabiliteit van dat formaat volledig om.

Bij Office Open XML is veel meer van alle functionaliteit beschreven. (je kunt natuurlijk ook niet in de MS Office source code kijken zoals bij OpenOffice).

  • -2 / 4

Anonymous Coward op Vrijdag 4 April 2008 08:33

image

Het is een simplistische opgave om het verschil te benadrukken. Als je sommige onderdelen bekijkt zal zelfs OOO teveel bevatten voor sommige gebruikers.

Het punt wat ik probeer te zetten is dat het niet uit maakt hoe een document of folder tot stand komt, Acrobat, Office (welke dan ook), Print It, Wordpad o.i.d.
Het gaat erom dat wat je uit wilt wisselen, daar gaat het om. Als ik in fotoshop een project maak met 20-30-80 lagen om mijn artistieke ei kwijt te kunnen gaat er een png/gif of zo het internet op, een afdruk vanuit de printer naar familie, een grotere jpg oid om te showen. Mijn PSD bestand blijft bij mij, daar zit mijn artistieke werk in, niet het makkelijk maken voor anderen.
Als ik een document maak met allerlei berekeningen vanuit eigen gevonden gegevens deel ik deze gegevens ook niet uit, het resultaat mogen ze bekijken. Moet men de gegevens wel hebben kan ik daar een andere aanvulling op geven. Neem mailmerge, ik geef toch ook niet de hele database mee aan elke ontvanger? (lekker vreemd voorbeeld)

  • 2 / 2

edjez op Vrijdag 4 April 2008 21:02

image

Je verhaal gaat mank op 1 ding: niet alleen het resultaat telt, je moet documenten zoals jij ze bewerkt ook aan anderen kunnen doorgeven, inclusief alle (meta)data die voor het eindresultaat niet van belang is. De bedoeling is dat jij met applicatie 1 iets maakt, dat ik met applicatie 2 zonder problemen verder kan bewerken. Dus inclusief macro's, berekeningen enzovoort.

(Welke van de twee standaarden daar het meest voor geschikt voor is laat ik me bij gebrek aan kennis van beide formaten niet over uit, dus minnen is niet nodig).

  • 2 / 2

toiletpaper op Vrijdag 4 April 2008 09:11

image

Zo kun je bijvoorbeeld in ODF files willekeurige spreadsheetformules gebruiken of een willekeurige macrotaal of willekeurige binaire inhoud. ODF laat dat alemaal vrij en niet beschreven.
Ook dit loop je al een jaar te verkondigen alsof het iets nieuws is. Het feit negerend dat inmiddels meer dan 300 formula's document onafhankelijk gedefinieerd zijn, en dat 400 het doel is. Dus, dit feitje is niet lang meer actueel. Jammer, baseline, jammer, maar de concurrentie zit niet stil. Het formula gedeelte zal einde van dit jaar door het (hopelijk ethisch herstelde) ISO worden beoordeeld.

Ik ben benieuwd. Dit wordt de grote testcase voor ISO, zal het zich herstellen van de grote corrumpering door Microsoft? De wereld houdt haar hart vast.

In elk geval is het niet meer acceptabel dat China overruled kan worden door Malta, dit soort dingen moeten eerst gerepareerd worden voordat ISO nog een eerlijke breed gedragen office-standaard kan afleveren.


  • 3 / 5

baseline op Vrijdag 4 April 2008 11:21

image

Het feit negerend dat inmiddels meer dan 300 formula's document onafhankelijk gedefinieerd zijn, en dat 400 het doel is.

Je hebt het over op papier ontwikkelingen. De ontwikkeling van de formules in OASIS gaat supertraag. Al in 2004 is erkend in de TC dat deze formules ontbraken in ODF en nu zijn ze er nog niet. Het duurt al aanmerklijk langer dan de TC nodig had om de hele rest van ODf te ontwikkelen. Er is dus ook geen implementatie van die nieuwe formules, en het kan nog jaren duren voor er een applicaties bestaat die deze nieuwe formules allemaal correct implementeert. De formulas worden sowieso pas op zijn vroegst in de zomer van 2009 toegevoegd aan de ISO ODF formaat standaard.
En ik weet niet precies wat je bedoelt met onafhankelijk. Het zijn gewoon Sun en IBM die dat doen met OpenOffice en Lotus als basis.

  • -3 / 5

Bolleke op Vrijdag 4 April 2008 11:27

image zomerhack badge 3

De ontwikkeling van de formules in OASIS gaat supertraag.
Ik kan natuurlijk niet achter de schermen bij OASIS kijken, maar dit zijn dingen waar je goed over wilt nadenken, en die kunnen dus lang duren. Maar het feit dat ze er op dit moment niet zijn (wat dus ook lang en breed erkend is, zoals je zelf al aangeeft) is iets anders dan het argument van Microsoft.

Ik zal 'm nog even herhalen:

ODF is "by design" ongeschikt voor MS Office
^^ bijvoorbeeld omdat er "iets" met de structuur van ODF zou zijn waardoor formules een technische onmogelijkheid zouden zijn.

Ik heb nog altijd geen voorbeeld van iets dergelijks mogen vernemen, en ga er dus tot nader order vanuit dat dit een drogredenering betreft.

  • 4 / 4

toiletpaper op Vrijdag 4 April 2008 11:31

image

ODF is "by design" ongeschikt voor MS Office
Microsoft heeft nooit anders gewild, en plukt de druiven van hun gramschap.

Zie wat Bill Gates op de rechtbank zei, enkele dagen voor de eerste ODF TC meeting (elders in deze thread)

  • 2 / 4

toiletpaper op Vrijdag 4 April 2008 11:33

image

Betreffend bedoeld citaat

  • 1 / 1

baseline op Vrijdag 4 April 2008 11:59

image

ODF is "by design" ongeschikt voor MS Office

Dat is ook juist. Dat ligt dan echter weer aan andere zaken.
Bijvoorbeeld:
* Zo zijn in ODF bijvoorbeeld math elementen losse blobs. In Office Open XML kunnen math en office elementen worden gecombineerd en kun je bijvoorbeeld revisies bijhouden
* Zo heeft ODF geen goede ondersteuning voor custom XML elementen.
* Zo heeft ODF geen containerformaat dat de relaties tussen de verschillende deelbestanden vastlegt.
* ODF heeft geen performance features voor het snel verwerken van zeer grote spreadsheets.
* ODF ondersteund geen themas.

en ongetwijfeld nog een heleboel andere zaken.

  • -5 / 5

toiletpaper op Vrijdag 4 April 2008 12:10

image

tja, het feit dat MS wilde dat ODF zonder hun invloed zou ontstaan wordt genegeerd. Lees wat Bill gates enkele dagen voor de eerste ODF meeting zei op de rechtbank, en het zald uidelijk zijn.

"splendid isolation" is jarenlang een melkkoe geweest, en MS worstelt nu met de legacy, en de ambivalentie tussen monopolie en interoperabiliteit.

  • 2 / 2

baseline op Vrijdag 4 April 2008 12:16

image

Je bedoelt de eerst OpenOffice XML meeting.
De naam ODF is pas in 2004 in gebruik genomen toen het formaat eignelijk al gereeed was.
In 2002, 2003 en 2004 spraken we gewoon van het Open Office formaat. Je kujnt nu wel proberen daar met terugwerkende kracht een opendocument formaat van te maken maar het was gewoon een formaat bedoeld voor Open Office. Pas in 2004 stelde de EU aan OASIS voor om het Open Office formaat aan ISO voor te leggen (en tegelijkertijd aan Micrsoft om hun Office XML formaat te standaardiseren) en toen heeft men het formaat hernoemd naar OpenDocument (een fictieve document naam uit een EU rapport).

  • -3 / 5

toiletpaper op Vrijdag 4 April 2008 12:36

image

Het maakt niet uit, wat uitmaakt is de Bill Gates doctrine, in november 2002 voor de rechtbank heel duidelijk verwoord.
The first official ODF-TC meeting to discuss the standard was December 16, 2002 (volgens mij had ik deze datum al eerder genoemd vandaag)

Je weet heel precies war eht voer gaat, en je probeert alleen maar af te leiden.

De Gates doctrine is altijd die van isolation geweest, letterlijk door hem uitgesproken, tegen interoperabiliteit.

  • 0 / 2

baseline op Vrijdag 4 April 2008 12:50

image

Jij probeert een link te leggen tussen ODF en bill gates in 2002 maar in 2202 was er geen heelemaal ODF-TC maar een OOXF-TC. Er was geen sprake van dat OASIS probeerde een opvolger voor de MS Office formaten te creeren.

  • -3 / 5

toiletpaper op Vrijdag 4 April 2008 13:20

image

het gaat erom dat Microsoft hoewel bekend binnen Oasis geweigerd heeft om invloed uit te oefenen op ODF, en dat dat precies volgens de Bill Gates doctrine ook klopt, en nu zeg jij weer dat het niet uitgenodigd is. ik vraag me af hoe jij dat weet. Het was gewoon een Oasis-werkgroep, het had gewoon mee kunnen doen, en indien geweigerd een groot schandaal kunnen schoppen, maar dat wilde het allemaal niet, het wilde helemaal niet dat ODF zou aansluiten bij MS-Office, dat is gewoon exact zoals Bill Gates dat bedoeld heeft, twintig jaar lang, en ook gewoon op de rechtbank toe heeft gegeven

  • 3 / 3

baseline op Vrijdag 4 April 2008 16:37

image

Het was gewoon een Oasis-werkgroep, het had gewoon mee kunnen doen,

Het was gewoon een werkgroep binnen OASIS die een XML formaat voor Open Office aan het ontwikkelen was en wel zonder enigerlei doel om MS Office files te willen ondersteunen. Waarom zou MS daar interesse voor hebben.
Er zijn honderden projectjes binnen OASIS en andere organisaties zoals w3c. Je kunt niet aan alles meedoen en de Open Office TC lag dan al zeker niet voor de hand.

  • -3 / 3

toiletpaper op Vrijdag 4 April 2008 19:44

image

Zoals ik al zei, op een bepaald moment is de werkgroep begonnen aan de ontwikkeling van een office standaard, en daar had MS mee kunnen doen.
Ik geloof niet dat Sun en IBM MS met behoud van goed fatsoen hadden kunnen weigeren. Ik heb ook nooit vernoemen dat dat is gebeurd

  • 1 / 3

baseline op Vrijdag 4 April 2008 21:30

image

als MS een OpenOffice TC had gejoined had het direct ruzie geweest en had wel zeker ieder voorstel van MS op verzet gestoten. Zelf het alleen maar joinen van een Open Offcie TC had op alle OSS zsites als sabotage van MS beschouwd geweest. Bedenk wel dat er toen hele maal nog geen sprake was van een algemene Office standaard maar slechts een Open Office formaat. Een OSS kindje dus. Daar was men altijd al heel vinnig op MS.
Het is echt een lachwekkende voorstelling van zaken dat men vijf jaar geleden MS bemoeienis met een OpenOffice formaat geaccepteerd zou hebben.
Sterker nog als MS en MS partners nu de ODF TC zou binnen lopen om ODF meer compatbile te krijgen met MS Office dan zou de wereld te klein zijn.

ODF fans willen helemaal niet dat MS aan ODF komt. Ze willen alleen maar dat MS braaf het formaat gebruikt zodat het makkelijker wordt om MS Office te verslaan in de office suite markt. Een flut argument als bestaansrecht voor een office formaat. Bij elkaar geraapte webstandards in een Open Office jasje. Echt gek is het niet dat zelfs na zo lange tijd geen twee applicaties ODF interoperabel heeft weten te implementeren terwijl het toch juist het simpele meer interoperable formaat zou moeten zijn. Dat was zelfs de doelstelling.

  • -2 / 4

toiletpaper op Vrijdag 4 April 2008 21:35

image

als MS een OpenOffice TC had gejoined had het direct ruzie geweest en had wel zeker ieder voorstel van MS op verzet gestoten.
En daar komt Calimero weer....

  • 2 / 2

thieu op Vrijdag 4 April 2008 22:52

image

Ze willen alleen maar dat MS braaf het formaat gebruikt zodat het makkelijker wordt om MS Office te verslaan in de office suite markt.
Je geeft hier dus aan dat je het feitelijk met Toiletpaper eens bent inzake de Bill Gates doctrine van splendid isolation.
Want, aangezien ODF open source is zou het voor MS een eitje moeten ODF goed en volledig te ondersteunen. Sterker nog, MS roept zelf ook altijd dat concurrentie goed en gezond is. Aangezien ze volgens hunzelf "het beste officepakket" maken zou het geen enkel probleem moeten zijn om op kwaliteit te concurreren met andere officepakketten.

Jaja. Concurrentie is goed, echter alleen in náám en met een kennisachterstand voor de concurrent die daardoor heel veel extra moeite moet doen.

  • 3 / 3

baseline op Zaterdag 5 April 2008 08:50

image

Want, aangezien ODF open source is zou het voor MS een eitje moeten ODF goed en volledig te ondersteunen.

Zelfs OpenOffice, de implementatie die vanaf dag 1 bij het standaardisatie betrokken is geweest, die het formaat heeft geleverd waarop ODf is gebaseerd en die als de referentie applicatie wordt gezien, ondersteunt na 5 jaar ODF nog niet heel goed.
Andere applicaties kunnen zeker niet meer ondersteuning bieden dan OOo omdat het zonder OOo te reverse engineeeren vaak onduidelijk is hoe er met de specs moet worden omgegaan.
MS kan dus zeker niet zo maar even ODF implementeren zeker aangezien MS OFfice heel anders functioneert en is opgebouwd en dus niet aansluit bij ODF. Zo kan niet alle OFfice functionaliteit in ODF kwijt (zonder extenties) en bevat MS Office ook niet alle functionaliteit die je in ODF kan opslaan.

  • -3 / 3

Diogenes_Isher op Zaterdag 5 April 2008 09:26

image

...en aldus had baseline/albert, zeer tevreden, het laatste woord. Laten wij hopen dat het daar nu eens inderdaad echt bij blijft... ;-)

  • 1 / 3

thieu op Zaterdag 5 April 2008 13:10

image

Je gaat uitgebreid in op één zinnetje van mij, dat meer plagend bedoeld was, met een hele hoop technische rookgordijnen. De andere principieel veel belangrijkere zaken worden genegeerd.

Of je bent het er inderdaad mee eens... :-)

  • 3 / 3

toiletpaper op Zaterdag 5 April 2008 13:18

image

MS kan dus zeker niet zo maar even ODF implementeren zeker aangezien MS OFfice heel anders functioneert en is opgebouwd en dus niet aansluit bij ODF.
OpenOffice kan in 99% een perfecte vertaling maken van een Word naar een ODF bestand, en ook weer terug.
MS Office zou dit zeker ook kunnen, desnoods kopiëren ze de betreffende code van OpenOffice

MS Office kan in 99% een perfecte vertaling maken van een Word naar een OOXML bestand, en ook weer terug.

(Wat betreft Excel is dit einde van het jaar ook mogelijk zonder extensies in ODF 1.2.)

  • 3 / 3

baseline op Zaterdag 5 April 2008 20:46

image

OpenOffice kan in 99% een perfecte vertaling maken van een Word naar een ODF bestand, en ook weer terug

Bron ?

  • -3 / 3

toiletpaper op Zondag 6 April 2008 00:50

image

eigen ervaring, al jarenlang maak ik ODF van Word en omgekeerd, zonder informatie-verlies.

  • 2 / 2

toiletpaper op Vrijdag 4 April 2008 12:39

image

een fictieve document naam uit een EU rapport
hoe kan nou een naam fictief zijn?

net zoals OOXML op een keer over OpenXML genoemd moet worden, jij probeerde zelfs dit in Wikipedia te veranderen, Hans Bos probeert het hier ook de hele tijd.

het gaat niet om XML, het gaat om OfficeXML, de naam OpenXML suggereert de helft, en is ook veel te generiek.

fictief.... bah, laat me niet lachen... pathetisch

ISO heeft het over
ISO/IEC DIS 29500
Information technology -- Office Open XML file format

Het zou handig zijn als Mcirosoft dit ook zou doen, en zich niet via een fictief naampje probeert veel meer toe te eigenen

  • 3 / 3

baseline op Vrijdag 4 April 2008 12:55

image

hoe kan nou een naam fictief zijn?

Omdat het iets beschrijft wat niet bestaat. De EU heeft een rapport laten schrijven waarin met een fictief open document formaat als referentie nam. Toen de EU daarna vroeg aan de OASIS Open Office TC om hun formaat binnen ISO te laten standaardiseren heeft de OASIS TC hun naam veranderd naar open document format TC.

  • -4 / 4

toiletpaper op Vrijdag 4 April 2008 13:17

image

wat eheft dat te maken met de Bill Gates doctrine van splendid isolation?

  • 0 / 2

edjez op Vrijdag 4 April 2008 21:07

image

Je stelt een vraag, hij geeft een relevant antwoord en je bent verbaasd? Het is ook niet snel goed tussen jou en Baseline, wel?

  • 1 / 3

toiletpaper op Vrijdag 4 April 2008 21:46

image

Ik stelde een retorische vraag, want ik gaf zelf het antwoord

  • 0 / 2

Bolleke op Vrijdag 4 April 2008 12:17

image zomerhack badge 3

Hehe, een concreet lijstje. :-)
* Zo zijn in ODF bijvoorbeeld math elementen losse blobs. In Office Open XML kunnen math en office elementen worden gecombineerd en kun je bijvoorbeeld revisies bijhouden
ODF gebruikt een bestaande standaard voor wiskundige formules. Die kun je goed vinden of niet, maar dat zegt dus niks over ODF.
Maar kon het oude Word dit dan wel? Ik heb geen Word, kun je anders ergens een binaire .DOC online knallen met zo'n formule met revisies erin? Ben wel benieuwd hoe de verschillende office-applicaties daar mee omgaan, namelijk.

* Zo heeft ODF geen goede ondersteuning voor custom XML elementen.
Misschien begrijp ik je verkeerd, maar het hele doel van een documentstandaard is toch juist het gebruik van uniforme XML? Anders kun je net zo goed pure XML met een stylesheet gebruiken.

* Zo heeft ODF geen containerformaat dat de relaties tussen de verschillende deelbestanden vastlegt.
Dit snap ik niet. Welke relaties doel je bijvoorbeeld op?

* ODF heeft geen performance features voor het snel verwerken van zeer grote spreadsheets.
Hier hebben we het al 1000 keer over gehad: performance hoort niet in het formaat, dat regel je maar in de applicatie.

* ODF ondersteund geen themas.
Wat voor themas?

  • 3 / 3

Bolleke op Vrijdag 4 April 2008 12:21

image zomerhack badge 3

Zo zijn in ODF bijvoorbeeld math elementen losse blobs
Oh, nog een klein technisch puntje: BLOB staat voor Binary Large OBject. MathML secties in ODT zijn echter gewoon tekst, dus de term BLOB is /zeer/ ongelukkig gekozen (laten we het daar maar op houden ;-)).

  • 3 / 3

baseline op Vrijdag 4 April 2008 13:07

image

ODF gebruikt een bestaande standaard voor wiskundige formules. Die kun je goed vinden of niet, maar dat zegt dus niks over ODF
Dat zegt wel wat over ODF. MathML is een presentatiegericht formaat bedoeld voor webpaginas. ODF is een edit formaat bedoeld voor veel meer dan presentatie doeleinden. Bijvoorbeeld voor onderheoud, reviewen en versies/versiebeheer. MathML in ODF is daar niet geschikt voor maar wordt wel toegepast in ODF.
Verder is de MathML in ODF echt fantastisch beschreven:
<define name="mathMarkup">
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<element>
<anyName/>
<ref name="mathMarkup"/>
</element>
</choice>
</zeroOrMore>
</define>
Daar kun je zelfs Office Open XML math instoppen en dan valideert het nog.
(dat is ook handig want OpenOffice stopt er bijvoorbeeld een eigen mathml variant in en niet de officiele w3c standaard versie)

  • -3 / 3

Bolleke op Vrijdag 4 April 2008 13:22

image zomerhack badge 3

MathML is een presentatiegericht formaat bedoeld voor webpaginas. ODF is een edit formaat bedoeld voor veel meer dan presentatie doeleinden. Bijvoorbeeld voor onderheoud, reviewen en versies/versiebeheer.
Nee, daar is het niet voor. Een office-formaat is bij uitstek bedoeld voor presentatie. Voor zaken als versiebeheer heb je hele andere, gespecialiseerde tools.

"Do one thing, and do it well."

Voor serieus versiebeheer mis ik in beide formaten nog wel wat meer features. Zoals comments bij je wijzigingen, diffs tussen verschillende versies, hoe om te gaan met conflicten etc.etc.etc.etc.etc. "Onderhoud" snap ik sowieso niet, en "reviewen" eigenlijk ook niet. Dit zijn volgens mij allemaal zaken die in applicaties thuishoren, niet in documentformaten. Revisieinformatie is daarbij een duidelijk twijfelgeval, maar ik vind het eerlijk gezegd in beide standaarden ongeveer even brak geimplementeerd. Als ik ergens revisies van wil bijhouden gebruik ik liever Subversion, dan hou ik tenminste wat nuttigs bij.

Maar misschien is dit wel de essentie van waarom wij het zelden eens zijn: een compleet andere filosofie over hoe software, en dus ook de bijbehorende formaten, zou moeten werken.

  • 4 / 4

baseline op Vrijdag 4 April 2008 15:46

image

Als jij dent dat Office XML formaten zijn voor presentatie dan begrijp ik wel dat je ODF acceptabel vindt.
Maar eigenlijk zijn html/css en PDF daar veel geschikter voor.
Dat zijn presentatieformaten bij uitstek.

  • -4 / 6

toiletpaper op Vrijdag 4 April 2008 19:46

image

Ik heb jou regelmatig horen benadrukken dat de presentatie-kant van OOXML belangrijk is, ik snap niet waarom je dat nu afdoet.

  • 1 / 3

baseline op Vrijdag 4 April 2008 13:19

image

performance hoort niet in het formaat, dat regel je maar in de applicatie.
Een onzin argument want bepaalde performance aspecten kunnen alleen behaald worden als de informatie daarvoor in het formaat zijn opgeslagen. Dat geldt voor allerlei formaten.
Denk maar aan video formaten die kunnen beginnen met spelen voordat het complete videobestand binnen is.
Of bij een picture formaat waar je ruimte in je getoonde webpagina kunt reserveren zonder direct het plaatje te tonen omdat die informatie in het begin van het file is vastgelegd.
en in Office open XML kun je vast leggen welke welke cellen een formule bevatten en eventueeel herberekend moeten worden terwijl je in ODF alle cellen daarvoor moet aflopen.

  • -3 / 3

toiletpaper op Vrijdag 4 April 2008 13:33

image

Office open XML kun je vast leggen welke welke cellen een formule bevatten en eventueeel herberekend moeten worden terwijl je in ODF alle cellen daarvoor moet aflopen.
Wat Bolleke bedoelt is dat de applicatie zelf performance verbeteringen kan toevoegen, dat hoeft niet in de standaard, is zelfs ongewenst.
De hele standaard gaat juist over het scheiden van informatie en techniek/implementatie.

  • 4 / 4

baseline op Vrijdag 4 April 2008 14:49

image

Natuurlijk is een perfromance ook een zaak van de implementatie. Echter een formaat kan daar ook aan bijdragen door die informatie mede op te slaan ipv van elke keer op nieuw op te moeten bouwen.
Een database slaat een index ook op en bouwt die niet elke keer opnieuw op als de database geopend wordt terwijl dat zou kunnen.

  • -3 / 5

toiletpaper op Vrijdag 4 April 2008 19:50

image

Een database slaat een index ook op en bouwt die niet elke keer opnieuw op als de database geopend wordt terwijl dat zou kunnen.
Precies, en een index is een database-implementatie-techniek om een relationele database snel te maken. Het heeft niet met relationele database-standaarden, zoals Codd-normalisatie te maken. Codd had het daar niet over, maar de database-leveranciers wisten wel dat dit kon helpen. Een goede database-design tool volgens Codd verbergt het maken van indexen ook voor de designer. Dat gebeurt automatisch.

  • 2 / 2

baseline op Zaterdag 5 April 2008 09:36

image

Als we ooit het beschrijving formaat van een RDBMS gaat vastleggen in een ISO standaard dan denk ik niet dat die standaard erg succesvol wordt als je er naast hoe je de data in tabellen vast legt ook geen info in stopt over hoe je indexen vastlegt.
Codd heeft dan wel bijvoorbeeld beschreven hoe relationele databases er uit moeten zien in zijn bekende twelve rules maar ondanks dat je volgens die regels geen indexen nodig hebt om een database relationeel te noemen zal je toch geen rdbms kunnen vinden dat geen indexen ondersteunt.

  • -2 / 2

toiletpaper op Zaterdag 5 April 2008 10:37

image

Het gaat erom dat in de Codd-standaard geen indexen worden genoemd, dus in een implementatie-vraagstuk betreffend performance, een standaard hoort daar niet voer te gaan.

Een RDBMS ga je niet in een ISO standaard vastleggen, je legt ook gen tekstverwerker vast in een ISO standaard, of een auto.

Uit de theorie van Codd is SQL gedestilleerd, dat is een ISO standaard. In SQL kun je niet aangeven dat je een bepaalde index wil gebruiken. Je kunt wel aangeven dat je de resultaten gesorteerd wilt ontvangen, maar het is aan de database om te beslissen hoe dat moet gebeuren.

Samengevat, performance verbeteringen horen niet in een (ISO) standaard, ze zijn implementatie-afhankelijk. Want als je ze wel opneemt, dan zet je een slot op innovatie, want dan ga je implementators opleggen hoe ze tot een betere performance kunnen komen. Dat kun je beter aan de implementators over laten, dan aan ISO. Ook hier zit OOXML er naast

Maar het is een welles niets spelletje, dus laat maar zitten. Jij wil alleen dat goedvinden wat er in OOXML zit, niet wat redelijk is. Ik schrijf dit ook niet ten behoeve van de discussie, want wat wij doen noem ik niet discussiëren. Ik schrijf het omdat ik niet graag wil dat onzin die jij verzint, of die MS verzint, of Brian Jones verzint niet zonder repliek blijft. Maar ikb eperk me tot webwereld, jij gilt het de wereld rond, dat is het verschil tussen ons.

  • 4 / 4

baseline op Zaterdag 5 April 2008 19:37

image

Toch heb je geen gelijk. De performance die je kan winnen door informatie op te slaan hoort interoperabel te zijn. Anders zou iedere implementatie zij eigen performance info moeten iopslaan om vergelijkbare perforance te halen.
Als Microsoft deze informatie uit het formaat had gelaten en de performance informatie op propriety wijze in de Office files had opgeslagen. Bijvoorbeeld met een extentie of als embedded data dan was iedereen op de achterste benen gaan staan. Nu kan iedereen deze optionele informatie gebruiken of niet gebruiken.

En SQL heeft misschien geen create index in de standaard staan toch is er geen DBMS dat niet het commando create index kent. Nu maakt het bij database niet uit omdat indexen niet interoperable moeten zijn en bij het rdbms horen maar bij office bestanden is interoperabliteit wel belangrijk en is het niet zo acceptabel als iedere implementatie zijn eigen performance features in een file gaat opslaan.

  • -2 / 2

toiletpaper op Zondag 6 April 2008 00:49

image

Nu maakt het bij database niet uit omdat indexen niet interoperable moeten zijn en bij het rdbms
Het is jouw voorbeeld.......
Documenten horen volgens mij niet interoperabel op gebied van performance te zijn, maar op gebied van informatie.

Nogmaals, het opnemen van performance-eigenschappen zet innovatie op slot, want je dwingt implementeurs om performance parameters te implementeren.

Je hebt dit zelf goed uitgelegd.

  • 3 / 3

baseline op Vrijdag 4 April 2008 13:31

image

Zo heeft ODF geen containerformaat dat de relaties tussen de verschillende deelbestanden vastlegt.

Dit snap ik niet. Welke relaties doel je bijvoorbeeld op?

In de OPC filecontainer van Offcie open XML worden de relaties tussen alle fileparts en alle externe elementen vastgelegd in kleine relationship files die onderdeel vormen van je filecontainer. Als je dus een logo of thema file hebt van de huisstijl kun je die omzetten naar ander files zonder in de main document code naar de relatie/link te zoeken en die aan te passen.
Ook kun je zonder het hele document te scannen van elk filepart zien OF en door welk ander filepart deze wordt aangeroepen. Als je bijvoorbeeld in een ODF file een plaatje weggooit moet je eerst het hele ODF documetn scannen om te zien of het plaatje nog ergens aangeroepen wordt en of je niet je document corrupt maakt dor het plaatje te verwijderen. (luie implementaties zullen het plaatje gewoon laten staan ok als het niet meer aangeroepen wordt)

Je kunt ook in de relation ship parts in 1 keer zien welke externe links er in het document voorkomen en deze zonodig wijzigen (handig als je office documenten in je web/intranet hebt hangen).

  • -4 / 4

toiletpaper op Vrijdag 4 April 2008 13:42

image

Je kunt ook in de relation ship parts in 1 keer zien welke externe links er in het document voorkomen en deze zonodig wijzigen (handig als je office documenten in je web/intranet hebt hangen).
Document paradigma. De rest van de ICT doet het met informatie (zoals het acroniem aangeeft)

  • 2 / 2

toiletpaper op Vrijdag 4 April 2008 13:45

image

Documenten op het intranet worden op aanvraag gegenereerd, vanuit informatie.

Zelfs Microsoft snapt dit, tenminste, dat hoop ik voor hun

  • 2 / 2

Bolleke op Vrijdag 4 April 2008 13:50

image zomerhack badge 3

In de OPC filecontainer van Offcie open XML worden de relaties tussen alle fileparts en alle externe elementen vastgelegd in kleine relationship files die onderdeel vormen van je filecontainer.
Los van het feit of dit wenselijk is: dat had de oude DOC ook niet, dus dat kan nooit een argument voor de backwards-compatibility zijn. En daar hadden we het hier over, laten we de overige verschillen - die er in overvloede zijn - alsjeblieft buiten de discussie houden.

  • 6 / 6

baseline op Vrijdag 4 April 2008 14:22

image

Je moet niet je scope nu proberen te veranderen. We hadden het helemaal niet over .DOC files maar over het design van ODF vergeleken met dat van OOXML.

Je zei zelf:
ODF is "by design" ongeschikt voor MS Office
En ik gaf daarna voorbeelden waarom ODF niet voldoet voor functionaliteit die OOXML icm MS Office (of andere implementaties) wel bieden.

  • -3 / 5

Bolleke op Vrijdag 4 April 2008 14:39

image zomerhack badge 3

Je zei zelf:
ODF is "by design" ongeschikt voor MS Office
En ik gaf daarna voorbeelden waarom ODF niet voldoet voor functionaliteit die OOXML icm MS Office (of andere implementaties) wel bieden.
Wacht even - ODF zou ongeschikt zijn omdat het niet de functionaliteit van MS Office (lees: de oude binaire formaten) goed ondersteunt. Dit ging namelijk over backwards-compatibility.

Als de beste dingen die je met ODF niet kunt die je kunt bedenken zaken zijn die pas met OOXML in MS Office zijn geintroduceerd - dus /nieuwe/ versies - dan haal je dat argument toch onderuit?

  • 5 / 5

baseline op Vrijdag 4 April 2008 14:56

image

Ik denk dat je je vergist als je zegt "oude binaire formaten".
De binaire formaten staan niet stil.
Ook de binaire formaten worden gewoon doorontwikkeld hoor.
In Office 2007 heb je ook gewoon een nieuwere versie van de binaire formaten. (BIFF 12 behorend bij Office 12)

  • -3 / 5

Bolleke op Vrijdag 4 April 2008 17:10

image zomerhack badge 3

Ik denk dat je je vergist als je zegt "oude binaire formaten".

*huil*

Ik leg het nog 1x uit:
Het argument voor MS om ODF te negeren was dat het geen achterwaartse compatibiliteit zou bieden. M.a.w., alle documenten in de oude binaire formaten zouden niet in ODF weergegeven kunnen worden. Achterwaartse compatibiliteit gaat over bestaande documenten!!!

Ik kan het niet op meer manieren duidelijk maken. Ik heb ook nog geen bewijzen gezien dat dit inderdaad zo zou zijn.

  • 5 / 5

edjez op Vrijdag 4 April 2008 21:14

image

Volgens mij was het niet HET argument, maar één van de argumenten.

  • -2 / 2

baseline op Vrijdag 4 April 2008 13:47

image

[quote][quote]* Zo heeft ODF geen goede ondersteuning voor custom XML elementen.[/quote]

Misschien begrijp ik je verkeerd, maar het hele doel van een documentstandaard is toch juist het gebruik van uniforme XML? Anders kun je net zo goed pure XML met een stylesheet gebruiken.[/quote][/quote]

Binnen bedrijven is het heel gebruikelijk om Office content te combineren met applicatie content. Denk aan het maken van facturen, standaard brieven, polissen, afschriften en weet ik veel wat al dies meer zij. Je kunt met Office Open XML veel makkelijker je eigen applicatie data combineren met Office content en deze toch prima onderscheiden.
Ook kun je denken aan eigen archiveringinformatie die je kunt toevoegen aan documenten of ondersteuning voor geautomatiseerde verwerking van electronische documenten/formulieren bijvoorbeeld met eigen referentienummers. Je kun in electronische dossiers bijvoorbeeld de documenten markeren met dossiernummers, clientnummers en document type/nummers of met welke info dan ook.

  • -4 / 4

Bolleke op Vrijdag 4 April 2008 14:05

image zomerhack badge 3

Je kunt met Office Open XML veel makkelijker je eigen applicatie data combineren met Office content en deze toch prima onderscheiden.
Misschien begrijp ik je nog steeds verkeerd, maar wat heeft de mogelijkheid tot koppeling met externe velden te maken met custom XML?

  • 4 / 4

baseline op Vrijdag 4 April 2008 14:19

image

Hoezo externe elementen.
Je kunt de organisatie eigen data intern juist herkenbaar in het document opslaan.

  • -4 / 4

toiletpaper op Vrijdag 4 April 2008 21:43

image

Dat is een domme toepassing van office-XML, de kracht zit juist in het integreren met andere applicaties, en de documenten op aanvraag te creëren. je moet de data niet in het document zetten, dat is het oude paradigma, daarmee gebruik je een innovatie om juist het oude te doen. Leuk, maar waarom zou je dan een XML-standaard willen? Het is al heel lang mogelijk om meta-tags in office-documenten te zetten. Ouwe wijn in nieuwe zakken omdat er sprake is van een onbegrepen innovatie.

  • 2 / 2

baseline op Zaterdag 5 April 2008 09:25

image

Dat toont slechts dat je geen idee hebt waar het om gaat bij documenten.
Als je documenten genereert dan moet je toegang hebben tot de bron applicatie waar de data inzit.
Als je de documenten echter communiceert dan heeft de ontvanger geen toegang tot de originele bron. Bovendien wil je dan een gearchiveerde versie en die wil je dus niet telkens gegenereerd hebben maar 100% zoals deze is verzonden.

Als wij bijvoorbeeld documenten aanmaken aan naar een externe printstraat sturen dan zit daar heel veel extra informatie bij over de documenten en hoe we die afgedrukt willen. Die info kan ook in de documenten worden opgenomen. Dat maakt het veel flexibeler om bijvoorbeeld veschillende documenten te laten afdrukken en op verschillende tijden te laten verzenden. Tegelijkertijd willen we ze ook wel door een derde partij laten archiveren en daarvoor kun je dan ook voor ons relevante data opnemen in het document.
Ook willen we bijvoorbeeld documenten scannen en dan bepaalde data elementen die we daarbij direct herkennen door ofwel barcodes, kixcodes of OCR herkenning van referentie info (registratienummer/klantnummer/referentienummer/sofinummer/loonheffingennummer) die velden als xml data in de gescande documenten opnemen zodat de documenten makkelijk geautomatiseerde verwerkt kunen worden in bijvoorbeeld electronische dossiers of postvakken.

Er zijn echt eindeloos veel toepassingen te bedenken hoe je een documentenstroom in je organisatie en daarbuiten kunt beinvloeden met extra informatie opgenomen in die documenten.

  • -3 / 3

toiletpaper op Zaterdag 5 April 2008 10:24

image

Er bestaat bad practice in de automatisering,d at zeker, en het is zaak van een software elverancier dat hij ook bad practice ondersteunt
Als je de documenten echter communiceert dan heeft de ontvanger geen toegang tot de originele bron. Bovendien wil je dan een gearchiveerde versie en die wil je dus niet telkens gegenereerd hebben maar 100% zoals deze is verzonden.
Voor dat soort doelen gebruik je een ander formaat, daarvoor is et Office XML formaat niet bedoeld. Voor weergave archivering kun je beter PDF gebruiken, of die MS-variant, die hetzelfde doet. Voor versturen ander een ander ook. Maar voor benadering van informatie in documenten, daarvoor wil je het liefst de XML-features gebruiken, en dat gaat zonder meer het snelste in een database die XML kan verwerken.
Natuurlijk kun je ook miljoen XML-documenten op een opslag bewaren, en dan die een voor een openen en kijken wat er in staat. Maar dat zou ik bad practice noemen.
Als wij bijvoorbeeld documenten aanmaken aan naar een externe printstraat sturen dan zit daar heel veel extra informatie bij over de documenten en hoe we die afgedrukt willen. Die info kan ook in de documenten worden opgenomen.
Precies, daarvoor is PDF uitermate gechikt.
(registratienummer/klantnummer/referentienummer/sofinummer/loonheffingennummer) die velden als xml data in de gescande documenten opnemen zodat de documenten makkelijk geautomatiseerde verwerkt kunen worden in bijvoorbeeld electronische dossiers of postvakken.
Je noemt hier echt document onafhankelijke informatie-entiteiten, het is zonder meer handiger om die anders te verwerken/op te slaan in een database.
Natuurlijk zijn er uitzonderingen mogelijk waardoor je terug meot vallen op het legacy document paradigma, maar dat moet uitzondering zijn, geen regel, anders doe je iets fout, of je ehbt een heel speciaal bedrijf.
Er zijn echt eindeloos veel toepassingen te bedenken hoe je een documentenstroom in je organisatie en daarbuiten kunt beinvloeden met extra informatie opgenomen in die documenten.
Precies wat ik zeg, er kunnen redenen zijn, maar in feite wil je het liefst een document als weergave in PDF opslaan, bijvoorbeeld met een referentienummer, en in een database, de informatie die het PDF in weergave-formaat bevat (ik beschrijf heel summier een mogelijke infrastructuur als voorbeeld), zodat je snel kunt zoeken zonder allerlei bestanden te moeten openen. Dat is werkelijk de praktijk, of hoort het te zijn.
Maar ik weet dat dit op veel kantoren nog nieuw is, en dat ze heel erg in documenten denken, en niet in staat zijn om in informatie-termen te denken. Niet zo belangrijk verder in deze discussie.

Ik geef mijn visie, en zoals ik die in mijn professionele leven regelmatig tegenkom. Dat ze het bij jullie anders doen, tja, moeten jullie zelf weten.

Ik zou hier nog heel veel over kunnen zeggen, maar daar is webwereld neit het forum toe, en daarbij laat ik me betalen voor dit soort gedachten

  • 3 / 3

baseline op Vrijdag 4 April 2008 15:28

image

* ODF ondersteund geen themas.

Wat voor themas?

Bijvoorbeeld:
help.adobe.com/...edbaf-7f83.html

  • -5 / 5

Bolleke op Vrijdag 4 April 2008 17:06

image zomerhack badge 3

Wat voor themas?

Bijvoorbeeld:
http://help.adobe.com/en_US/Connect/6.0/Presenter/help.html?content=WS3a32668ae8e7984c61736e10b1fbedbaf-7f83.html
Eh... dat is toch gewoon een template? Dat heeft toch niks met "het formaat" te maken? Als ik een template voor een website maak kan dat toch ook zonder dat het in de HTML-spec staat???

  • 5 / 5

baseline op Vrijdag 4 April 2008 21:08

image

Theme files kun je vervangen in een OOXML file en daarmee in 1 keer het theme veranderen
Bij files gebaseerd op een template kan dat volgens mij niet zo maar.

  • -3 / 3

toiletpaper op Vrijdag 4 April 2008 21:40

image

Dit is eigenlijk al oude techniek. Het scheiden van weergave en inhoud is al enige tijd aan de gang in CMS systemen, en daar kun je inderdaad een thema zo vaak wisselen als je wilt. Ik zie niet in waarom dat in Office-XML anders zou zijn.

  • 1 / 1

Acarya op Zondag 6 April 2008 12:03

image

In OpenOffice wel, hoor:

This extension will add a new item to the File - Templates menu that allows to assign a new template to the current document. All styles and formatting will be loaded from that template and the document will behave as it was created using that template.

Geen idee of M$-office ook zoiets heeft?

  • 2 / 2

Scheurleer op Vrijdag 4 April 2008 17:23

image

Verbijsterend. De argumenten die je hier noemt zijn op z'n minst arbitrair. Voorbeeld: je hebt het over zaken als het snel verwerken van gegevens. Dit soort performance eigenschappen (want daar praat je over) regel je niet in een standaard, en al helemaal niet in een opslag/uitwisselingsstandaard. Applicatie en hardware zijn hierin zeer belangrijke factoren die weinig tot niets met deze standaard te maken hebben.

Bovendien: zelfs al zouden je argumenten waar zijn, dan nog zou het beter zijn geweest als Microsoft effort had gestoken in het completeren en verbeteren van de ODF standaard in plaats van het ontwikkelen van een eigen standaard. (NB. Ik weet dat ik hiermee aangeef dat ik OOXML beschouw als een MS standaard.).

  • 6 / 6

baseline op Vrijdag 4 April 2008 21:18

image

Micrsoft was allang bezig met XML files voordat Sun hun Open Office formaat in OASIS verder ging ointwikkelen. Het lag noot voor de hand dat Microsoft ging bijdragen aan een Openoffice formaat en niemand vroeg daar ook om.
Het had toen eerder klachten opgeleverd.
Dit soort uitspraken over MS die zogezegd zou hebben kunnen bijdragen aan ODF ontwikkeling zijn puur uit de lucht gegrepen en zijn zonder uitzondering van na de ISO standaardisatie van ODF eind 2005. Toen het te laat was om nog zinvol bij te dragen. Een rookgordijn om te kunnen beweren dat er geen meerdere formaten nodig zouden zijn.
En dat terwijl dat OOXML gewoon een heel ander formaat is dat heel andere doelen dient enm dat ODF niet geschikt is voor de doelen en ook niet zo maar even aangepast kan worden om als zodanig geschikt gemaakt te worden.
En dat is nog afgezien van de vraag of er ooit een ians zou zijn dat men in de OASIS TC ook ooit maar 1 wijziging van MS zou accepteren. Er is geen enkele reden voor om dat aan te nemen want wijzigingen die niet strookten met de implementatie van OpenOffice zijn in de OASIS TC eigenlijk altijd geblokkeerd.

  • -3 / 3

toiletpaper op Vrijdag 4 April 2008 21:33

image

En dat is nog afgezien van de vraag of er ooit een ians zou zijn dat men in de OASIS TC ook ooit maar 1 wijziging van MS zou accepteren.
Dit is pure speculatie en kan op geen enkel wijz worden onderbouwd
Om in jouw woorden te blijven, het is een rookgordijn dat MS optrekt om te verklaren waarom het niet wil meewerken aan een gezamenlijke office XML-standaard.

  • 3 / 3

baseline op Zaterdag 5 April 2008 09:01

image

Dit is pure speculatie en kan op geen enkel wijz worden onderbouwd

Het eerste wat de OASIS TC deed was compatibliteit met bestaande Office files afwijzen als een doelstelling.
Ook is het in ieder geval al zeker dat de ODF foundations verzoeken in de OASIS TC om betere compatibiliteit met MS Office files te bereiken door Sun en IBM zijn getorpedeerd.
Waaruit zou met ooit moeten opmaken dat men wel.
Er is zelfs vanuit de OASIS TC door leden gezegd dat verzoeken om functionalitiet worden geblokkerd als Sun/OOo die niet in hun applicatie willen inbouwen.
Er is dus voldoende indicatie dat de OASIS TC niet positief staat tegen compatibiliteit met MS Office files en MS Office functionaliteit.

Waaruit blijkt in godsnaam dat de OASIS TC openstaat voor aanpassingen om functionliteit van MS Office en backwards compatibiliteit met MS Office files te ondersteunen. De speculatie zit volgens mij volledig aan jou kant omdat er geen enkele indicatie is dat met bij OASIS op inbreng van MS zit te wachten maar voldoende indicaties dat men helemaal geen andere input wil.

  • -2 / 2

toiletpaper op Zaterdag 5 April 2008 13:02

image

Het eerste wat de OASIS TC deed was compatibliteit met bestaande Office files afwijzen als een doelstelling. \
bron?


  • 1 / 1

baseline op Zaterdag 5 April 2008 17:07

image

De OASIS TC archiven

  • -3 / 3

toiletpaper op Zondag 6 April 2008 00:44

image

Link?

  • 1 / 1

baseline op Donderdag 10 April 2008 11:26

image

De OASIS archieven zijn vrij doorzoekbaar.
Ik twijfel er niet aan dat je in die openheid de betreffende meeting notes zelf kan vinden.
Ik heb al eerder aangegeven dat ik me niet geroepen meer voel om elk bronnetje te linken in discussies waarbij anderen ook zuinig zijn met hun broninformatie.
Ik vind het leuk dat je suggereert dat MS wel betrokken had kunnen zijn bij de ODF ontwikkeling maar niemand heeft nog geen enkele bron getoond waaruit blijkt dat in 2002 MS een gewenste partner was in die OASIS OpenOffice XML TC.

  • -2 / 2

Scheurleer op Vrijdag 4 April 2008 22:42

image

Het lag noot voor de hand dat Microsoft ging bijdragen aan een Openoffice formaat en niemand vroeg daar ook om.
Eerlijk gezegd vind ik dit een bijzonder veelzeggende opmerking. Nog afgezien van het feit dat je dit zou kunnen aanbieden, ook al wordt het niet gevraagd, illustreert dit de onwil om mee te werken. En bezien vanuit Microsoft was dit terecht: ze hadden er geen belang bij. Integendeel, ze hadden alles te verliezen, nl. een min of meer monopoliepositie in Office land.

En dat terwijl dat OOXML gewoon een heel ander formaat is dat heel andere doelen dient enm dat ODF niet geschikt is voor de doelen en ook niet zo maar even aangepast kan worden om als zodanig geschikt gemaakt te worden
Ben ik niet met je eens. OOXML dient geen ander doel dan ODF, d.w.z. geen ander doel bezien vanuit requirements die aan een Office standaard gesteld worden. Uiteraard dient OOXML wel een ander doel dan ODF als het gaat om het continueren van de belangen van Microsoft.

Of ODF niet zomaar geschikt kan worden gemaakt waag ik te betwijfelen. D.w.z. dat het wellicht niet "zomaar" zal gaan (er zal wel moeite voor moeten worden gedaan, en het zal best een poosje duren). Maar ik denk wel dat het mogelijk is.

Ik vind het prima dat je een andere mening hebt dan ik. Geen punt. Maar je verdedigt je met een argumentatie op grond van techniek, die door diverse mensen in deze discussie als aantoonbaar onjuist worden gekwalificeerd.

  • 5 / 5

baseline op Zaterdag 5 April 2008 09:09

image

Nog afgezien van het feit dat je dit zou kunnen aanbieden, ook al wordt het niet gevraagd, illustreert dit de onwil om mee te werken
Wat een vreemde opmerking. er zijn tienduizenden zo niet honderdduizende projecten vanuit de OSS community waarvoor Microsoft niet wordt gevraagd. En als Ms dan niet spontaan zich aanbiedt bij dergelijk OSS project stat dat gelijk aan onwil ?

Je draait de wereld der logica op zijn kop.

Als men in OASIS serieus een Office formaat had willen ontwikkelen voor de hele wereld waarom ga je dan niet eerst langs bij markleider Microsoft om hen te vragen hun formaat en kennis en capaciteit te doneren en een lead role in de ontwikkeling te nemen. Dan ga je niet een TC oprichten voor bedoeld voor het maken van een nieuwe Open Office XML formaat met vooraf al als basis het bestaande OpenOffice formaat en met vooraf al een lijst van partijen betrokken bij OpenOffice.
Als het eerste wat je doet bij het ontwikklelen van een nieuwe formaat is het negeren van de marktleider en c ompatibiliteit met de producten van die markleider afwijzen dan ben je niet uit op participatie van die marktleider.

  • -2 / 2

Scheurleer op Zaterdag 5 April 2008 10:31

image

* Niet voor de oprichting in de TC al een voorstel had voor deelenemers waar geen Micrsoft of anderszins in MS Office formaten geinsteresseerde partij bijzat. (ofwel met had MS gewoon genegeerd bij de oprichting van de TC)
* Niet bij de oprichtingsbijeenkomst van de TC al meteen had besloten om compatibiliteit met MS documenten niet als een doel te zien.

Waarom zou MS zich aanbieden om een Open Office formaat te gaan ontwikkelen.

Zodra een andere partij (bijvoorbeeld MS) ODF gaat gebruiken om andee functionaliteit in onder te brengen valt elke interoperabiliteit van dat formaat volledig om.

Beste Baseline,
Dit zijn een aantal quotes van jou in deze discussie. Kijk nu nog eens naar wat je hebt geschreven, kijk naar de door jou gevoerde argumentatie in het licht van dit draadje van de discussie, Jouw reactie naar mij toe is dat ik de logica omdraai. Maar kijk nog eens goed wat je hier zelf geschreven hebt.

  • 5 / 5

toiletpaper op Zaterdag 5 April 2008 12:50

image

Wat een vreemde opmerking. er zijn tienduizenden zo niet honderdduizende projecten vanuit de OSS community waarvoor Microsoft niet wordt gevraagd. En als Ms dan niet spontaan zich aanbiedt bij dergelijk OSS project stat dat gelijk aan onwil ?
Het gaat in deze discussie om een "open standaard" definitie, niet om een "open source" project.

  • 2 / 2

toiletpaper op Zaterdag 5 April 2008 12:53

image

Als men in OASIS serieus een Office formaat had willen ontwikkelen voor de hele wereld waarom ga je dan niet eerst langs bij markleider Microsoft om hen te vragen hun formaat en kennis en capaciteit te doneren en een lead role in de ontwikkeling te nemen.
lead role is overdreven, zou kunnen maar daar begin je niet mee, je begint eerst met over een te komen dat er een standaard nodig is.
Hoe kun jij weten dat MS niet gevraagd is te participeren?

Je zuigt dit gewoon uit je duim, want jij kunt onmogelijk alle communicaties kennen.

  • 3 / 3

toiletpaper op Zaterdag 5 April 2008 12:58

image

Het had ook omgekeerd gekund, want de oprichting van een TC gaat openbaar. Microsoft had kunnen zeggen: "Toevallig, jullie willen een open office standaard ontwikkelen, wij ook, alten we kijken of dat samen kan."

Het is een beetje Calimero om te stellen dat MS niet mee mocht doen, ze zitten bij Oasis, en hebben vaker met IBM en Sun aan standaarden gewerkt.

Ik blijf erbij dat het de schuld van MS is dat we nu met twee open office standaarden zitten, waarvan een bijna exclusief op MS is afgestemd, en de ander niet.

Dit is gewoon een voortzetting van de splendid isolation doctrine van Bill Gates.

  • 4 / 4

baseline op Zaterdag 5 April 2008 15:42

image

Hoe kun jij weten dat MS niet gevraagd is te participeren?
Heeft Sun of OASIS er baat bij om een dergelijk verzoek te verbergen?
Er was ook nooit reden voor. Het ging toch om een Open Office formaat.
Ik ga ook niet als ik een een nieuw linux filesysteem ga ontwikkelen langs bij MS om te vragen of ze NTFS kennis willen doneren.

  • -2 / 2

ArjenB op Zaterdag 5 April 2008 16:35

image

Microsoft zou er op dit moment baat bij hebben als ze aan konden tonen dat ze wel geprobeerd hadden om aansluiting te vinden bij ODF.

Zou MS er baat bij hebben zo'n poging stil te houden?

  • 3 / 3

baseline op Zaterdag 5 April 2008 19:16

image

Dat lijkt me niet. Er was nooit een reden voor MS om zich aan te sluiten bij ODF. Het was nooit bedoeld als een formaat dat de MS Office formaten zou opvolgen maar als een format om de SWX formaten van OpenOFfice op te volgen.
Er is geen enkele indicatie dat er ooit iemand Microsoft input wilde voor het ODF formaat maar voldoende info dat men in de Open Office TC zich verzette tegen aanpassingen tbv compatibliteit met bestaande formaten.
Dat zegt gewoon genoeg.

  • -3 / 3

toiletpaper op Zondag 6 April 2008 00:43

image

r is geen enkele indicatie dat er ooit iemand Microsoft input wilde voor het ODF formaat maar voldoende info dat men in de Open Office TC zich verzette tegen aanpassingen tbv compatibliteit met bestaande formaten.
Er is geen enkele indicatie voor het tegendeel. Het is gewoon nooit geprobeerd vanwege de Gates doctrine van splendid isolation.

  • 2 / 2

ArjenB op Zondag 6 April 2008 09:54

image

Met andere woorden "ik ga niet met je praten want ik kan niet met je praten ook al heb ik dat nog niet geprobeerd". Die heb ik een tijd niet gehoord. Leuk!

  • 3 / 3

baseline op Donderdag 10 April 2008 11:30

image

Heb jij je al aangemeld op het webpagina van TON.
Misschien wordt daar wel over de toekomst van het land beslist (misschien ook niet ;-) ).
Je kan echter nu open participeren.
En je moet later niet aankomen met andere voorstellen want je had nu gewoon mee kunnen doen. Er is ten slotte een open participatie mogelijk en iedereen is uitgenodigd.

  • -2 / 4

ArjenB op Donderdag 10 April 2008 12:04

image

Ze hebben de website dichtgezet, verdikkeme :-( Dus ik kan me niet meer mengen tussen de verlichte geesten die onder andere opperen dat geestelijk gehandicapten preventief geruimd moeten worden.

  • 1 / 1

ArjenB op Donderdag 10 April 2008 12:05

image

Nog wel bedankt voor het idee, plusje.

  • 0 / 0

toiletpaper op Vrijdag 4 April 2008 11:29

image

Je hebt het over op papier ontwikkelingen. De ontwikkeling van de formules in OASIS gaat supertraag. Al in 2004 is erkend in de TC dat deze formules ontbraken in ODF en nu zijn ze er nog niet
Natuurlijk, het gaat uitsluitend om definities, niet om implementaties, daar houden standaard-definities zich terecht niet mee bezig. Implementaties moeten de standaard volgen, niet omgekeerd. Maar goed, hier moet ik werkelijk zuchten.......

Anyway, de Formula business is sinds afgelopen zomer goed ops toom gekomen. In een half jaar zijn er meer dan 300 geformuleerd, en de enkele tientallen die nog moeten worden gedaan komen er zeker aan voor najaar dat ODF 1.2 aan ISO wordt voorgedragen.

Er zijn 4 conformance levels gedefinieerd, de 4e, waarin wetenschappelijke formules staan is de moeilijkste, de overige drie zijn gereed en zijn de dingen die gewone stervelingen doen met eens spreadsheet doen.

Ik had dit exact hetzelfde eergisteren ook al geschreven, en vorige maand ook. Als je dat had gelezen had ik het niet hoeven te herhalen.

Het is gewoon zuigen wat je doet, steeds hetzelfde zeggen, in de hoopd at ik op een keer niet meer reageer. Dat doe je ook op Wikipedia, dat doe je overal.


  • 2 / 2

baseline op Vrijdag 4 April 2008 12:10

image

Het zuigen is wat jij doet.
De suggestie dat alle driehonderd formules zijn ontwikkeld in een half jaar is lachwekkend. Ze zijn daar al jaren mee bezig.
In de eerdere road map die ze bij OASIS publiceerden zouden de fomules al begin 2007 gereed moeten zijn en nog in 2007 goedgekeurd moeten zijn door OASIS.
Nu zijn ze nog steeds niet af.
Ook zitten ze bij ISO nog steeds te wachten op de 1.1 versie van ODF. Volgens OASIS een heel belangrijke versie omdat die allerlei aanpassingen voor gehandicapten zou bevatten maar deze versie is nooit aan ISO voorgelegd terwijl bijvoorbeeld OOo de suggestie wekt deze non-ISO versie wel toe te passen.
Eerst zien en dan geloven is het devies bij wat de OASIS TC produceert.

  • -3 / 5

toiletpaper op Vrijdag 4 April 2008 13:48

image

De suggestie dat alle driehonderd formules zijn ontwikkeld in een half jaar is lachwekkend. Ze zijn daar al jaren mee bezig.
Het is misschien lachwekkend maar wel waar, ze zijn heel traag geweest met de eerste honderd, en laatste half jaar zijn er extra mensen opgezet en wordt de formula-standaard in hoog tempo gereed gemaakt.

En misschien lopen ze wat uit op de roadmap, dat kan, hoeveel ICT projecten ken jij die uitlopen?
In elk geval halen ze nu snel in, heel snel.

Gewoon eerlijk zijn, en relevante argumenten gebruiken, je bereikt het niveau modder gooien, je lijkt je collega's MS adeptenw el, die dat ook doen.

Moet ej niet een paar keer IBM zeggen?

Doe maar, misschien lucht dat op

  • 2 / 4

Hans Bos op Vrijdag 4 April 2008 09:32

image

1 Wat is bij MS de definitie van een document?
2 Wat is bij MS de definitie van "semantisch documenten, tot en met complete 'interfaces' naar bedrijfsinformatie." zoals bedoelt in OOXML

Ik weet niet of Microsoft een echte "definitie" voor een document gebruikt. Zelf zie ik het als een "drager voor informatie". Net zoals een boek. Daarin kunnen tekst, plaatjes, combinaties, tabellen, inhoudsopgaven etc staan.
Maar een "digitaal document" maakt ook andere dingen mogelijk. Bijvoorbeeld in de tekst (al dan niet verstopt voor een gewone lezer) extra informatie opnemen over die tekst.
Je leest bijvoorbeeld: "Achternaam, voornaam - Sofinr: 121212223" in een document.

Jij snapt als mens direct dat het een naam is met een sofinummer. De computer ziet alleen een rijtje letters en cijfers. Maar als je er codes in verwerkt zodat de tekst voor de mens hetzelfde blijft als hierboven, maar voor de computer dit wordt:

<begin Burger><begin Naam>Achternaam, voornaam<einde Naam> - sofinr: <begin Sofinummer>121212223<einde Sofinummer><einde Burger>

Dan weet de computer precies waar het om gaat. Een programma kan dan bijvoorbeeld het sofinummer interpreteren en "aanklikbaar" maken voor de eindgebruiker en er een koppeling naar een belastingdienst database van maken etc.

Daarmee is een link naar een "semantisch document" gemaakt. Het document bevat niet alleen de informatie maar ook een indicatie (metainformatie) over wat die informatie precies is. Vaak met als doel om het document niet alleen door tekstverwerkers te laten gebruiken, maar ook door geautomatiseerde systemen etc.

Hier is een voorbeeld van hoe Microsoft dat doet met MS Office en Open XML:
office.microsof...2204261033.aspx
(het is een demo video voor architecten en ontwikkelaars als doelgroep)

Hier is een voorbeeld van MindManager die gebruik maakt van deze mogelijkheid in Open XML:
mindjetlabs.com...le-Formats.aspx

Documenten worden er niet veel groter door. Als je het niet gebruikt, zit het er niet in. Het zal ook voor tekstdocumenten over het algemeen niet de berekening zijn die wordt meegestuurd of opgenomen, maar alleen een indicatie waar de informatie voor staat.

Voor eindgebruikers levert dat leesbare documenten, voor computer/toepassingen levert dat 'interpreteerbare' documenten en informatie.

  • -3 / 3

Anonymous Coward op Vrijdag 4 April 2008 09:59

image

Dat bedoel ik, wat heb ik als brieflezer aan deze extra data? Van alle documenten die uitgewisseld worden is maar een heel klein percentage bedoelt om de "extra" data te gebruiken.
Nogmaals wat heeft men hier aan als deze "extra" data specifiek bedoelt is? Binnen je eigen organisatie zal een document veel meer waarde hebben als deze info er bij zit, naar buiten toe is het ballast. Daarnaast is deze "onzichtbare extra" opnieuw ballast, immers gaat deze niet mee in de printer, daar licht het "succes" van pdf, het maakt niet uit hoe je hem maakt, het is leesbaar, druk ik hem af is hij net zo leesbaar maar ben ik de zoekfunctie kwijt. Nu is Adobe ook zijn doel voorbij geschoten met ontiegelijk grote reader, ik gebruik daar een kleiner minder functioneel readertje voor, ik hoef het alleen te lezen.

  • 4 / 4

toiletpaper op Vrijdag 4 April 2008 10:33

image

Je kunt altijd een leesbare, platform onafhankelijke van meta-data ontdane versie van je document produceren, middels PDF of anderszins.

Maar OOXML en ODF gaan over andere dingen. Het document-paradigma nadert zijn einde. We gaan over naar databases, naar informatie, in plaats weergave.

Vergelijk het met grote websites, die niet meer uit afzonderlijke HTML-pagina's bestaan, maar uit CMS gegenereerde pagina's

XML maakt het mogelijk, zoals Hans Bos al aangaf, te zoeken naar "geadresseerde", "postcode gebied van geaddresseerde", en alle mogelijke documenten die ooit aan zo'n deelverzameling zijn verstuurd.
Afhankelijk van de lezer kunnen deze dan in Speech, braille, grote letter, kleine letter, etc worden weergegeven.

De weergave (in jouw geval PDF) wordt losgekoppeld van de informatie.

Dit is waar het eigenlijk om gaat in de XML-office-standaarden. Dat gezeur van compatibiliteit met Word is onzin, want over vijf jaar weet niemand meer wat Word is. Als het goed is wordt office-informatie door een keur van applicaties ontsloten, en al die applicaties zijn instaat om een weergave te produceren, amar dat is niet waarover het gaat. Waar het om gaat is de informatie.

Nogmaals, kijk hoe grote websites functioneren, dat is het voorland, middels PHP, AJAX, Java, C# kan de informatie ontsloten worden.
----------___-
Daarom, nogmaals, het steeds terugverwijzen naar binaire Word is kenmerkend voor mensen die niet goed begrijpen hoe het kantoor van de toekomst gaat functioneren. Zonder enige conversie moet ik in staat zijn informatie te tonen in HTML, PDF, of whatever. het Office-document bestaat niet meer, de Office-XML-document standaard heft eigenlijk niets meer met documenten te maken.

Een applicatie als Tex was zijn tijd ver vooruit, IBM met SGML (1986) ook, Docbook (sinds 1991), en dergelijke dat zijn vooruitstrevende voorbeelden van het Office van de toekomst.

Het is heel begrijpelijk dat Microsoft hier ambivalent in staat, want enerzijds, met Sharepoint etc, doen ze hier aan mee, maar van de andere kant, hun exclusieve marktaandeel gaat verloren, en dat is zeker. Wat ze doen is tijd winnen, innovatie op slot zetten.

Ondanks al dat baanbrekende werk van IBM in 1986 moest de wereld nutteloze binaire Office-documenten verwerken tot in 2003, alleen omdat Microsoft er niet in slaagde middels innovatie hun businessmodel te vervullen. Maar ook het vasthouden aan het oude heeft niet geholpen, gezien hun beursontwikkeling

  • 4 / 4

Anonymous Coward op Vrijdag 4 April 2008 11:11

image

Hier kan ik best in meekomen, mogelijkheden zijn legio en zullen alleen maar toenemen, maar waar stopt het woord document en begint het woord programma?
Ik verwoord het misschien slecht, maar "tekstverwerker" is om teksten te bewerken, een spreadsheet is om berekeningen te maken en een uitkomst te tonen, een database is om (grote) hoeveelheden data te rangschikken, filteren en presenteren. Dit alles tezamen (en meer) is een Office suit, maar vormt toch geen document meer? Inderdaad, bedrijf technisch is een CRM pakket met een Officesuit goed op elkaar afgestemd een utopie, maar dat heeft toch niets meer met de correspondentie te maken?
Ik zal het te simplistisch zien, maar alle documenten die ik krijg bevatten alleen uitkomsten van spreadsheet's, producten van tekstverwekers in kolommen, tabellen, enz, eventueel een aftreksel van de database in lijst met artikelen. De methode die gebruikt is om dit tot stand te brengen is niet relevant, hier kunnen zelfs bedrijfs geheimen zitten.
Dat we een bewerkbare eenheid zouden krijgen maakt dat we in andermans werk gaan kloten, dat we er eventueel iets in kunnen veranderen maakt niet dat we het mogen.
Binnen de organisatie willen we dit wel, maar niet naar buiten toe, wat we naar buiten uitwisselen is vele malen eenvoudiger dan OOXML/ODF, daar is door de vrijheid en OS karakter ODF beter geschikt voor. Als deze genoeg functionaliteit bied om ook intern meer mee aan te kunnen hoeft deze daar geen directe uitwisselbaarheid met MS bij te hebben.
Neem de belasting dienst, als deze op OOO zou zitten kunnen ze met PDF al een elektronisch document afleveren dat semi onveranderbaar mij van info/aanslag voorziet. Ik heb het achterliggend tot stand komen niet nodig, geven ze met ODF een invulformulier moet er al geregeld worden dat ik de begeleidende teksten zelf niet kan veranderen, immers moet ik daar aan voldoen. Opnieuw geld hier dat wat er ook mogelijk is en wordt, ik dit juist niet allemaal zou willen delen, het document moet "vast" staan.
Hier en in andere discussies wordt alles op één hoop gegooid, web pagina's, documenten, "semantisch documenten, tot en met complete 'interfaces' naar bedrijfsinformatie." worden aan elkaar gehangen terwijl dit niets meer met "een document" te maken heeft.
Een web pagina kan documenten bevatten maar een document geen web pagina wat moet ik mezelf voorstellen bij een "interface" in een document? Een document met bedrijfsinformatie snap ik, maar hoe moet ik dat "interfacen" vanuit hun brochure?
Stel eerst eens vast wat nu een document is voordat je een "semantisch documenten, tot en met complete 'interfaces' naar bedrijfsinformatie." bouwt en er dan een document uit wil halen.

  • 4 / 4

Bolleke op Vrijdag 4 April 2008 11:24

image zomerhack badge 3

Als het alleen om semantiek zou gaan zou men natuurlijk gewoon kunnen volstaan met XML, dat is er immers voor gemaakt.
Echter, in een office-formaat wil je ook andere dingen kwijt kunnen. Je wilt bijvoorbeeld opmaakinformatie kwijt (wat is het lettertype, hoe groot, is het bold of italic etc., dit zijn de simpele voorbeelden) en waarschijnlijk ook structurele informatie (is het een kop - en zo ja, welk niveau?, is het een paragraaf, moet ik het opnemen in de inhoud of index, is het een voetnoot etc.). Misschien geen zaken die een gemiddelde gebruiker nodig heeft, maar wel onmisbaar als je iets serieuzer met je tekstverwerker omgaat (bijv. omdat je een boek schrijft, of in de huisstijl van je bedrijf moet blijven).

Al dit soort dingen moeten in een standaard eenduidig beschreven worden. Bijvoorbeeld, in HTML betekent de tag <p> dat je met een paragraaf te maken hebt. Iedereen die een browser maakt weet dus dat hij met de tekst tussen <p>-tags iets moet doen om duidelijk te maken dat het om een paragraaf gaat (meestal gebeurt dit door wat witruimte voor en na de tekst open te laten, maar in boeken is het b.v. meestal een inspringing van een paar letters).

Als hier geen eenduidige beschrijving van zou zijn is het onmogelijk om een programma te schrijven dat op de gewenste manier met je document omgaat. Een van de grote kritiekpunten op OOXML is dat het reactief is tov MS Office. Daarmee bedoel ik dat het beschrijft wat MS Office uitpoept, zonder er duidelijk bij te zeggen waarom dat is. Een voorbeeld is de waarde in een cel in een spreadsheet. Die waarde kan floating point zijn, maar voor zover ik kan beoordelen is nergens duidelijk gespecificeerd wat het verschil is tussen wat Excel ervan maakt en wat er opgeslagen wordt. B.v. Excel kan 26 weergeven (omdat je je cel op "decimalen" hebt gezet) maar in je document staat eigenlijk 25.999999.

  • 5 / 5

Anonymous Coward op Vrijdag 4 April 2008 11:58

image

Dat er op die punten een te groot verschil is komt omdat de makers verschillende ideeën hebben over wat er onder "document" verstaan wordt.
Kijk bij van Dale eens onder document, als we dat als basis nemen is "semantisch documenten, tot en met complete 'interfaces' naar bedrijfsinformatie." een totaal andere invalshoek, hier schieten "techneuten" (niet negatief bedoelt) wel vaker het doel voorbij, we stoppen het er in omdat het kan en omdat soms, sommige mensen het misschien wel kunnen gebruiken.
Met wordpad kan ik ook documenten maken, met Acrobat ook, met Word, Wp, OOO en al dies meer zij ook, maar wat voor doel heeft het document, daar liggen de speciale functies die in specifieke onderdelen hun functie kunnen hebben, niet voor correspondentie.

  • 4 / 4

edjez op Vrijdag 4 April 2008 21:26

image

niet voor correspondentie.
Het gaat dan ook om het traject vóór het document de uiteindelijke correspondentie is. Neem iet wat vrij simpel is en veel gebruikt wordt: revisie. Tijdens het heen-en-weer koppen van het document is het belangrijk dat iedere applicatie weet wat de status van een revisie is (welke wijzigingen zijn de "actieve"), welke wijzigingen zijn er daarvóór geweest en van wie waren die, wat was het oorspronkelijke document?

Is niets specifiek voor een Office-pakket trouwens, bv AcrobatPro kan het ook, en vrij uitgebreid zelfs. Terwijl dat bij uitstek de applicatie is voor een correspondentie-formaat.

  • 2 / 2

baseline op Vrijdag 4 April 2008 14:06

image

innovatie op slot zetten.

Sorry hoor maar als ODF iets niet doet is het wel innoveren.
ODF is gewoon het ophoesten van een redelijk mislukt OOo formaat en dat aanmekaar plakken met een paar stokoude matig doorgebroken w3c standaarden uit de vorige eeuw. Wat is er in godsnaam vernieuwend aan ODF, de java applets die je erin kan proppen of de OLE linking and embedding ?

OOXML heeft weliswaar ook een flink aantal stokoude features maar combineert dat ten minste ook weer met vernieuwingen voor Office documenten zoals de OPC, custom XML en DrawingML.

  • -3 / 3

toiletpaper op Vrijdag 4 April 2008 14:15

image

Nogal aspecifiek mopperen, kunnen we allemaal, is dat interessant?
Voor mij niet zo.


  • 3 / 3

baseline op Vrijdag 4 April 2008 14:29

image

Jij komt met beweringen dat Micrsoft met OOXML innovatie op slot zet.
Als ik dan juist aangeef dat het ODF is dat geen enkele innovatie bevat terwijl OOXML in ieder geval gedeeltelijk inovatief is met hele specifieke voorbeelden
dan vind jij dat aspecifiek ??

Tja, hoe meer specifiek wil je het eigenlijk hebben dan ?

  • -4 / 4

Anonymous Coward op Vrijdag 4 April 2008 15:14

image

Baseline, hoe krijg je het voor elkaar?
Prettig weekeind en heel veel geluk, zul je nodig hebben.

  • 4 / 4

toiletpaper op Vrijdag 4 April 2008 15:15

image

Ik ga heel precies uitleggen waarom MS innovatie op slot heeft gezet, en hun ambivalentie tussen interoperabiliteit en monopolie. Dat IBM en Tex en Docbook al tientallen jaren geleden hier waren aangekomen, namelijk het scheiden van weergave en informatie, endat MS,d aarentegen tot in 2003 met binaire Word-documenten liep te zeulen. Opd eze wijze heeft het tien-twintig jaar de innovatie op slot gezet.

En nu nog steeds, proberen bugs in Excel gecertificeerd te krijgen bij ISO, en dergelijke humbug. nog steeds houdt het de deur naar interoperabiliteit dus innovatie op slot door voornamelijk alleen backwardse compatibiliteit naar de slechte binaire documenten in stand te houden, in plaats voer een geheel nieuw Office-paradigma na te denken: informatie scheiden van weergave.

Waarom meot ik alles dubbel vertellenb ij jou?
Omdat jij misschien neit snapt waarom office-docuemtnen in XML moeten? Niet alleen omdat OpenOffice het ook doet, nee, er zit meer achter, er zit een nieuw paradigma achter, end at is wat er bij jou niet in wil gaan, en daarom snap je ook niet waarom dat MS jaren achter loopt door perse vast te houden aan een compatibiliteit naar iets wat in 1993 ooit is ingezet als een poging om de concurrentie buiten de deur te houden, en in 2002 door Gates op de rechtbank frank en vrij is erkend (hij had zelf niet in de gaten hoe belachelijk hij was), in plaats van het oude monopolistische document paradigma lost te houden en werkelijke innovatie en interoperabilteit op gang te brengen.

Nee, ze proberen eerst van een Excel bug een wereldstandaard te maken, gewoon, een schrikkeljaar meer of minder, who cares...





  • 4 / 4

toiletpaper op Vrijdag 4 April 2008 15:17

image

nogmaals excuus voor de spelfouten, ik heb de hele dag haast, maar teruglezend zie ik dat de tekst begrepen kan worden

  • 3 / 3

baseline op Vrijdag 4 April 2008 15:36

image

IBM was misschien nog een voorloper in het nog vrij ongestructureerde (denk validatie) SGML maar is dat sinds de SGML specifieke w3c format XML eigenlijk al nauwelijk meer.
Op XML gebied is bijvoorbeeld Micrsoft al juist wel een voorloper en innovator geweest en veel XML gerelateerde standaarden zijn ontwikkeld mede met behulp van Microsoft.

  • -3 / 3

toiletpaper op Vrijdag 4 April 2008 15:47

image

IBM was een voorloper in het scheiden van informatie en weergave, het was conceptueel voorloper.

De technische definitie in de huidige vorm kwam later: XML. Waar inderdaad MS een rol in speelde, maar vervolgens weigerde om dit zinvol toe te passen in een nieuw office-paradigma. En zelfs nu nog steeds niet informatie van weergave wil scheiden en backwardse compatibiltieit naar de bina........zie mijn reactie: toiletpaper 04-04-2008 15:15

met andere woorden, MS doet wel modern, maar wil gewoon zijn markt afschermen, en weigert om samen met anderen een standaard te definiëren waarin ook haar behoeften tot uitdrukking komen, nog steeds gewoon, de concurrentie buiten de deur houden en legacy ellende implementeren in nieuwe office-standaarden, en daarmee negeren dat er veel meer aan de hand is dan een klant die XML wil. De klant wil veel meer dan XML, de klant wil interoperabiliteit, maar dat wil MS niet of nauwelijks leveren, het past niet in hun cultuurtje.

Het is jammer dat MS zo groot is, en dat Malta evenzwaar telt als China, anders was OOXML nooit een standaard geworden, als je naar getalsverhouding van bevolking kijkt, dan heft OOXML lang niet de 2/3 meerderheid. Het had de steun van bananenrepubliekjes nodig om dit er door te krijgen.

Maar goed, het is een Pyrrus-overwinning, tijd rekken, wat extra geld uit de markt slepen, maar niet in de gaten hebben dat ze vanwege dit op den duur eigenlijk alleen maar verliezen, zoals ze al tien jaar lang eigenlijk alleen maar achteruit hollen. MS aandeelhouders weten dit knarsentandend goed.

Dit zal alleen maar doorgaan, en terecht.

  • 4 / 4

baseline op Vrijdag 4 April 2008 16:27

image

XML. Waar inderdaad MS een rol in speelde, maar vervolgens weigerde om dit zinvol toe te passen in een nieuw office-paradigma

MS is echter dus al wel vroeg begonnen met het veranderen naar een markup formaat.
blogs.msdn.com/...-1998-2006.aspx

  • -3 / 3

toiletpaper op Vrijdag 4 April 2008 19:41

image

Daar hadden de klantend an toch weinig mee te maken, want ze belven gewoon in hun binaire legacy voortrommelen

  • 3 / 3

Anonymous Coward op Vrijdag 4 April 2008 23:24

image

Hoe krijgen jullie het voor elkaar om elk bericht waar het woord "document" in voorkomt zo te reactie verknallen, gaan jullie nu zo door tot de ander 5500 OOXML pagina's doorgeworsteld zijn? Ga dan liever op MSN verder, of neem een voeten van de vloer ruimte, alsjeblieft zeg, niet nog meer van hetzelfde.

  • 1 / 3

Bolleke op Zaterdag 5 April 2008 10:57

image zomerhack badge 3

Hoe krijgen jullie het voor elkaar om elk bericht waar het woord "document" in voorkomt zo te reactie verknallen, gaan jullie nu zo door tot de ander 5500 OOXML pagina's doorgeworsteld zijn?
Oh, maar dat kan ik je wel even uitleggen hoor.
Er zijn heel veel mensen (waaronder ikzelf), technische mensen, die OOXML een verbijsterend slecht idee vinden. De redenen hiervoor lopen uiteen van puur technische (het is een brakke "standaard") tot meer filosofische (waarom 2 documentformaten als 1 ook zou voldoen).

De verwoede Microsoft-supporters doen alles wat in hun macht ligt om ons te overtuigen dat de wereld juist een betere plaats is met OOXML. Deze hele column/advertorial is daar een voorbeeld van. Aangezien ik niet wil dat iemand over een maand eens gaat Googelen op wat dat ODF en OOXML precies is en hier uitkomt en de (IMO verkeerde) conclusie trekt dat ODF volkomen bagger is en OOXML de hemel blijft ik met tegenargumenten komen.

Het grappige is dan weer wel dat de argumenten van de OOXML-supporters op lijken te raken. Bijvoorbeeld hier weer "thema's", die had ik nog niet gehoord. Als voorbeeld neemt men dan een Adobe applicatie - wat die er mee te maken heeft ontgaat mij verder, maar goed.
Het hele verhaal over externe datakoppelingen zit ook gewoon in ODF. En hoewel ODF echt nog niet perfect is (zijn standaarden ooit "af"? Zie HTML, versie 5 komt er alweer aan) heb ik tot nu toe voornamelijk argumenten ertegen gehoord (de inmiddels beruchte "glpyh-orientation-vertical" dicussie elder hier op WW) die echt als een tang op een varken sloegen.

Mijn favoriete is de tegenwerping dat ODF specifiek /niet/ bedoeld is voor legacy-compatibiliteit. Volgens mij geeft die haarfijn weer waar we verschillen. OOXML bevat dingen als buggy schrikkeljaren, opmaakinfo voor allerlei oude versies van pakketten - kortom, het verheft oude bugs uit MS Office tot onderdeel van de standaard. Bij de mensen van ODF hebben ze gezegd: niet goed, we beginnen met een schone lei. Om de conversie goed te laten verlopen moet je je applicatie fixen.
De weg van ODF lijkt mij toch echt beter, zeker met het oog op de toekomst. En bedrijven die MS Office gebruiken als veredelde database zijn sowieso suf bezig - vooral omdat de "database" uit die suite - Access - bekend stond om zijn "omvallende bitjes" en daaruit voortkomende datacorruptie... Googelen op "bugs Excel" geeft ook een hoop leuke resultaten. Maar daar gaat het allemaal niet om, bedrijven die zo verweven zijn met MS Office en haar binaire formaten hebben sowieso een hele klus om over te gaan naar een XML formaat, of dat nou ODF of OOXML is. De vraag is, grijp je deze gelegenheid aan om gelijk van een hoop ander oud zeer af te raken of niet?

  • 5 / 5

baseline op Zaterdag 5 April 2008 15:28

image

opmaakinfo voor allerlei oude versies van pakketten - kortom, het verheft oude bugs uit MS Office tot onderdeel van de standaard.

Dat geldt evenzo voor ODF alleen zijn compatibiliteitssettings bij ODF implementaties gewoon ongedocumenteerde zooi en kunnen nieuwe implementaties die meuk ook nog misbruiken om nieuwe issues in op te slaan. Bij OOXML is het een gelimiteerde set van settings uit het verleden die ook nog volledig beschreven zijn en is dat niet meer uitbreidbaar naar de toekomst.



  • -2 / 2

ArjenB op Zaterdag 5 April 2008 16:25

image

Een voorbeeldje zou aardig zijn? Anders wordt het wat moeilijk om je bewering op waarde in te schatten...

  • 3 / 3

Bolleke op Zaterdag 5 April 2008 16:42

image zomerhack badge 3

Dat geldt evenzo voor ODF alleen zijn compatibiliteitssettings bij ODF implementaties gewoon ongedocumenteerde zooi
Zoals ik het begreep biedt ODF een ingebouwde mogelijkheid om legacy-settings (of andere implementatie-specifieke settings) op te nemen. Dat lijkt mij persoonlijk de nette manier - als je die wilt gebruiken, prima, maar dan is het dus ook niet vreemd dat je document er in een andere implementatie op punten anders uit ziet (die heeft immers z'n eigen legacy). Veel belangrijker is dat de informatie (de inhoud) in het document toegankelijk blijft.

Ik zou als programmeur niet goed weten waarom mijn applicatie net zo debiel met schrikkeljaren om zou moeten gaan als Excel. Jij?

  • 4 / 4

baseline op Zaterdag 5 April 2008 18:13

image

Ik zou als programmeur niet goed weten waarom mijn applicatie net zo debiel met schrikkeljaren om zou moeten gaan als Excel. Jij?

Dat meeen je toch niet serieus neem ik aan. Je weet toch wel dat ODF ook seriele datum met afwijkende nulldatums ondersteunt in spreadsheet vanwege compatibiliteits issues
Bij ODF is het echter flexibeler zodat je in theorie onbeperkt veel datum formaten hebt terwijl je in OOXML maar twee seriele datumformaten hebt

In ODF:
You can store a date as an xsd date type (which is actually different from ISO 8601 in a few ways including the way to treat the year zero). What many people don't know is that in OpenOffice you can also store a date as a serial number. These two date formats are exactly the same in OpenOffice:
<table:table-cell office:value-type="date" office:value="55"/>
<table:table-cell office:value-type="date" office:date-value="1900-02-25"/>
Now, the two values above are considered the exact same date, on one condition, and that is if date-value tag looks exactly like this:
<table:null-date table:date-value="1900-01-01"/>
Here is what the ODF spec says for this element:
"The <table:null-date> element specifies the null date. The null date is the date that results in the value "0" if a date value is converted into a numeric value. The null date is specified in the element's table:date-value attribute. Commonly used values are 12/30/1899, 01/01/1900, and 01/01/1904"
Of course, the null-date value (essentially the epoch) could be set to anything, and that would change how you interpret that first date I show above. So while the anti-OpenXML folks are claiming that there are too many date bases in Open XML, in ODF you have an infinite number of date bases to deal with.
The values set here also affect calculations of course, but that never came up in the ISO review of ODF because as we all know by now there is no definition for spreadsheet calculations/functions. The upcoming draft of OpenFormula though which the OASIS folks are working on does indeed have these same behaviors where you convert a date into a serial value using the epoch before you perform the calculation.

  • -2 / 2

toiletpaper op Zondag 6 April 2008 00:39

image

Dat meeen je toch niet serieus neem ik aan. Je weet toch wel dat ODF ook seriele datum met afwijkende nulldatums ondersteunt in spreadsheet vanwege compatibiliteits issues
Iemand stelt jou een serieuze vraag, geef daar antwoord op, en kom daarna met een tegenvraag, anders wordt het zo'n lege discussie waarin iedereen elkaar alleen maar tegenvragen stelt.

  • 2 / 2

Bolleke op Zondag 6 April 2008 08:12

image zomerhack badge 3

Om maar eens met je eigen woorden te spreken:
Dat meeen je toch niet serieus neem ik aan.

De legacy in OOXML betreft een switch waarmee je aangeeft of je document wel of niet de -foutieve!- datumrekening van Excel moet volgen (1900 != leap year!!!). De null-date uit ODF specificeert slechts "start of epoch" - op Unix systemen traditioneel 1-1-1970.

Kortom, je hebt als implementator de keuze tussen:
1) numerieke data accepteren en deze berekenen a.d.h.v. een duidelijk gespecificeerde offset
2) 1900 wel of niet als schrikkeljaar zien met alle gevolgen van dien (wat niks met een offset te maken heeft, je loopt domweg een dag ernaast als je met data van voor 1 maart 1900 werkt)

Ik hoop dat je zelf het verschil tussen flexibiliteit en een afgrijselijke work-around ziet.

  • 4 / 4

baseline op Zondag 6 April 2008 11:31

image

De legacy in OOXML betreft een switch waarmee je aangeeft of je document wel of niet de -foutieve!- datumrekening van Excel moet volgen (1900 != leap year!!!). De null-date uit ODF specificeert slechts "start of epoch" - op Unix systemen traditioneel 1-1-1970.

Nee hoor. Het gaat in essentie om hetzelfde.
Door de begindatum op 31-12-1899 te zetten wordt de decimale datum in ODF namelijk bijna compatibel met de oude beruchte 1900 (die overigens al in Lotus 1-2-3 voorkomt).
Vanaf maart 1900 zijn ze dan hetzelfde. ODF implementaties gebruiken op die manier de startdatum voor het bereiken van bijna compatibliteit met oude spreadsheet bestanden.

OOXML gebruikt het 1900 decimale formaat dat 100% compatibliteit garandeert en het 1904 decimale formaat dat volledig correct wordt bepaald. ODF gebruikt een meer generieke oplossing die een 'bijna' compatibiliteit levert met oude decimale 1900 datum in spreadsheets maar die ook nieuwe complexiteit toevoegt doordat nu willekeurige decimale datums gecreerd kunnen worden afhankelijk van de implementaties terwijl daar eigenlijk geen behoefte aan is.

  • -2 / 2

toiletpaper op Zondag 6 April 2008 13:35

image

Ik vind de uitleg van Bolleke aannemelijker, want eht is gewoon bekend dat er een bug in Excel zit, al sinds Lotus 123 zeg jij? (ik dacht dat Excel geen opvolger van Lotus was)
Maar goed, al heel lang, end at deze bug gewoon een op een is overgenomen in een ISO standaard, met een workaround. Het is neit zo'n heel groot punt, maar het geeft wel aan in hoeverre OOXML vervuild is door de MS Office legacy, inclusief de bijbehorende bugs.

Er is geen sprake van een nieuwe goed bedachte standaard voor office-XML, maar het is gewoon de volgende successor op MS Word, die nu ISO status bereikt, en dat is inderdaad, heel jammer voor ISO, en voor ons allemaal.

  • 3 / 3

toiletpaper op Zondag 6 April 2008 14:42

image

ODF implementaties gebruiken op die manier de startdatum voor het bereiken van bijna compatibliteit met oude spreadsheet bestanden.
Dit is ook zo'n onzinnetje. Alsof ODF compatible wil zijn emt oude spreadsheets. Waarom? Wat betekent dat?
Het is de software die van het een naar het ander vertaalt.
De data-bestanden zelf compatible, wat moet me hierbij voorstellen? Volgens mij is dit een volkomen onzin-bewering.

Voor OpenOffice, om een spreadsheet te openen, maakt het niet uit hoe ODF de leap year oplost, en voor OpenOffice om een ODF te openen, maakt het ook niet uit hoe een spreadsheet dit oplost.
Is dit het niveau waarop jullie communiceren bij MS? Dan begrijp ik hoe OOXML is ontstaan op een keer een stuk beter

  • 3 / 3

Bolleke op Zondag 6 April 2008 15:50

image zomerhack badge 3

Nee hoor. Het gaat in essentie om hetzelfde.
Door de begindatum op 31-12-1899 te zetten wordt de decimale datum in ODF namelijk bijna compatibel
Misschien zie ik iets over het hoofd hoor, maar Excel rekent gewoon een dag teveel. Dat los je volgens mij niet op "door een andere startdatum te kiezen", een dag teveel blijft een dag teveel. Ze hadden het gewoon moeten fixen.

Prutsers.

  • 3 / 3

baseline op Zondag 6 April 2008 16:15

image

Excel rekent een dag teveel maar allerlei spreadsheets doen dat dus ook. Waaronder ook OpenOFfice. OpenOffice lost dat op door bij dergelijke bestaande lotus of excel spreadsheets de normale startdatum van het decimale datumformaat in spreadsheets een dagje terug te zetten als het in ODF opslaat. Daardoor kirjg je hetzelfde resultaat als een extra schrikkeldagje.

  • -2 / 2

ArjenB op Zondag 6 April 2008 17:19

image

Het is gewoon een fout, een die in OpenOffice overigens niet voorkomt. Je hebt wat moeite om toe te geven dat je verkeerd zit, he?

  • 2 / 2

baseline op Dinsdag 8 April 2008 18:02

image

Het was geen fout in Excel maar een bewuste keuze om compatibel te blijven met Lotus 1-2-3 de dominante spreadsheet in het verleden.
En met deze keuze heeft excel het verder prima gedaan. Het is niet alsof er er veel klachten waren over die keuze die overigens door de meeste spreadsheets is gemaakt. Ook OpenOffice ondersteunt dat.

  • -2 / 2

ArjenB op Dinsdag 8 April 2008 18:12

image

Een bewuste keuze kan ook een fout zijn. Een waarop je altijd nog terug kunt komen, want zeg nou zelf, hoeveel mensen gebruiken Lotus 1-2-3 nog? En dat OpenOffice andermans troep opruimt zou zelfs jij moeten waarderen :-)

  • 1 / 1

Bolleke op Dinsdag 8 April 2008 18:23

image zomerhack badge 3

En met deze keuze heeft excel het verder prima gedaan. Het is niet alsof er er veel klachten waren over die keuze die overigens door de meeste spreadsheets is gemaakt. Ook OpenOffice ondersteunt dat.
Err... "ondersteunen" (als in herkennen dat het om Excel gaat en handelen naar known bugs in dat pakket) is 1 ding, het opnemen in je eigen formaat of zelfs verheffen tot ISO-standaard is iets heel anders.

En er zijn genoeg klachten over Excel hoor. Mensen die de integriteit van hun data belangrijk vinden mijden het als de pest. En soms niet, en dan gaat het fout, en dan verbijstert iedereen er zich weer eens over.

  • 2 / 2

toiletpaper op Dinsdag 8 April 2008 21:10

image

Het was geen fout in Excel maar een bewuste keuze om compatibel te blijven met Lotus 1-2-3 de dominante spreadsheet in het verleden.
Daar begrijp ik niks van

Excel leest een Lotus bestand, en interpreteert de bug zoals het hoort
Excel schrijft een Excel bestand, waarom zou daar dan een bug in moeten zitten?
Waarom kan Excel niet als het Lotus leest of schrijft rekening houden met een bug, en als het Exel of ISO leest en schrijft daar geen rekening mee houden? Is het een zwakzinnigenclub, dat MS?
Zonder iets verkeerds te willenz eggen over zwakzinnigen overigens.

Waarom moet in het ISO bestand een bug zitten? Omdat er een in Lotus zat? En dat heeft MS door de ISO comiteetjes heengesleept, geen wonder dat er zoveel gestufd moest worden, dit is vreselijk, vreselijk, vreselijk, zwakzinnig. Belachelijk, te gek voor woorden, let zelf eens op wat je zegt, hoe kunnen wij jou nu nog ooit serieus nemen?

Ik heb het gevoel dat jij bent blijven steken in Jip en Janneke. Het lijkt mij dat zelfs jij dit met mij eens moet zijn.

Bestanden zijn niet compatible met elkaar, dat is Jip en Janneke taal, maar ik begrijp dat Brian en jij dat niveau niet hebben kunnen ontstijgen.

Hoe heten Jip en Janneke trouwens in het Engels? Zal ik het eens opzoeken in Wikipedia, of heb je dat lemma ook al verknoeit. Tegenwoordig kijk ik iedere keer in Wikipedia of jij in de history staat, want dat gebeurt regelmatig.

In het Engels zijn er twee versies, zeker een voor de Lotus gebruikers: Mick and Mandy
En een voor de Excel gebruikers: Bob and Jilly

In Engeland werden de illustraties mvan Fiep Westerdorp niet gebruikt, want hierdoor zouden Jip en janneke uitzien as negers, end at wilden ze in Engeland niet. Zou dat de reden zijn?

  • 2 / 2

toiletpaper op Dinsdag 8 April 2008 21:12

image

Misschien moet ik bij nder inzien grootscheeps bekend maken dat MS een clubje van uitstekende marketeers is, maar buiten dat, naast kundige programmeurs, vooral iedereen die wat te vertellen eehft zich gedraagt als een zwakzinnige. Nooit zo'n onlogische shit meegemaakt. En daar doen wij honderden reacties over discussiëren?

Waar is de drank, geef me een iorrel, nee geen single malt, die drinkt hAL ook, e ik wil nie top hem lijken, doe maar, eh, een armagnac, dan

  • 1 / 1

toiletpaper op Dinsdag 8 April 2008 21:15

image

Sinds dat de idioten die MS steunen, vidnen dat ze wat te vertellen hebben kan het alleen amar slechter gaan met de wereld.

Vertel nog eens, Albert, er zit een bug in ISO omdat er een bug zit in Lotus 123, want ISO wil compatibel zijn met Excel, dat compatible wilz ijn met Lotus 123, welk jaar?

Doet er niet toe, als het maar geen schrikkeljaar is, want daar raakt MS compleet van in de stress.

  • 2 / 2

toiletpaper op Dinsdag 8 April 2008 21:20

image

Ik geef het op, Hans Bos (luister je nog), lees eens terug, de zwakzinnigheid waaruit OOXML is opgebouwd, Al]bert, compleet verkokerd door duzienden uren vrije tijd op te offeren aan een standaard gebaseerd op Jip en Janneke, Brian Jones, zelfde laken een pak (zelfde stof een overall), klungelaars, zo nu stop ik ermee.

OOXML, ik zal het nog een keer zeggen, te zot voor woorden, OOXML wil compatibel zijn met Excel dat compatible wil zijn met Lotus. Klinklt logisch? Voor iemenad die achterlijk is wel. Lees nu volgende:

- Excel leest een Lotus bestand, en interpreteert de bug zoals het hoort
- Excel schrijft een Excel bestand, waarom zou daar dan een bug in moeten zitten?
- Waarom kan Excel niet als het Lotus leest of schrijft rekening houden met een bug, en als het Exel of ISO leest en schrijft daar geen rekening mee houden?

Is het een zwakzinnigenclub, dat MS?
Zonder iets verkeerds te willenz eggen over zwakzinnigen overigens.

Jongens, jongens, wat eenw egerpfilosofie, dat MS, gewoon belachelijk.

Dat ze een bug laten zitten in ISO, goed, niets is perfect, maar dat ze dan de rest van de wereld met een stalen gezicht voor kleuters uitmaken.

Gelukkig zijn er nog intelligente uitdagingen, en die zitten niet in OOXML. Maar in hele andere dingen die ik doe.

  • 2 / 2

toiletpaper op Dinsdag 8 April 2008 21:36

image

Jongens, jongens, wat een wegwerpfilosofie, gewoon belachelijk.

  • 1 / 1

ArjenB op Woensdag 9 April 2008 09:17

image

Ho ho, ik vind het prima als Albert single malt drinkt. Dat doe ik ook. Ik laat me door zoiets onbeduidends als ISO niet van de belangrijke zaken in het leven houden.

  • 1 / 1

toiletpaper op Woensdag 9 April 2008 09:33

image

Ik kan goed leven zonder single malt, als armagnac daarvoor in de plaats komt.

  • 1 / 1

ArjenB op Woensdag 9 April 2008 09:40

image

OK, maar waarom zou je zonder doen? Ommdat je het met een andere drinker oneens bent? Zonde. Als je van je flessen af wilt :-)

  • 1 / 1

toiletpaper op Woensdag 9 April 2008 09:49

image

je hebt gelijk, je kan ook een druppeltje jodium, een lepeltje honing, een scheutje port, en wat zout, en heide-bloesem-parfum en een keuteltje schapenpoep in je armagnac doen, maar dat is wel omslachtig.

dus, ik hou die lagavullin toch liever even zelf.

  • 1 / 1

toiletpaper op Woensdag 9 April 2008 09:50

image

en een snuifje gedroogde turf en as, niet te vergeten

  • 2 / 2

ArjenB op Woensdag 9 April 2008 09:59

image

Good lad. Slainte!

  • 1 / 1

Bolleke op Zondag 6 April 2008 18:15

image zomerhack badge 3

Daardoor kirjg je hetzelfde resultaat als een extra schrikkeldagje.
Ten eerste: het is helemaal niet hetzelfde - het is een workaround waarbij de door Excel gehanteerde (foutieve) datum wordt teruggerekend naar een (hopelijk) kloppende datum. Da's iets heel anders.

Ten tweede: aardig toch, dat de applicatie OpenOffice.org daar rekening mee houdt? Ze ruimen gewoon de zooi van Microsoft op.

  • 3 / 3

toiletpaper op Zondag 6 April 2008 20:58

image

Excel rekent een dag teveel maar allerlei spreadsheets doen dat dus ook.
Daar zijn we het over eens, dat is niet mijn probleem, en OpenOffice doet het ook als het een Excel-sheet opent, tja, wat moeten ze anders, als je een Excel-sheet juist wil interrpeteren.
Het probleem is dat deze bug opgenomen is in een ISO standaard, dat is een blunder van MS, van de eerste orde.

  • 2 / 2

toiletpaper op Donderdag 10 April 2008 01:30

image

So while the anti-OpenXML folks are claiming that there are too many date bases in Open XML, in ODF you have an infinite number of date bases to deal with.
Als je wil uitleggen hoe datums werken in ODF, waarom citeer je dan niet uit de documentatie van ODF, waarom citeer je iemand die citeert en daarna interpreteert. Dat maakt discussies wazig en onzuiver, maar ik neem aan dat dat jouw bedoeling is.

Dit stukje tekst wat jij weergeeft is duidelijk anti-ODF gekleurd, de manier van uitdrukken: "anti-OpenXML folks are claiming...." spreekt boekdelen. Waarom niet objectief bespreken wat er werkelijk in de standaard staat, komt dat slecht uit, misschien?

  • 1 / 1

baseline op Zaterdag 5 April 2008 15:38

image

Het grappige is dan weer wel dat de argumenten van de OOXML-supporters op lijken te raken. Bijvoorbeeld hier weer "thema's", die had ik nog niet gehoord. Als voorbeeld neemt men dan een Adobe applicatie - wat die er mee te maken heeft ontgaat mij verder, maar goed.
Goh, al je een nieuw argument aanbrengt dan raken je argumenten op en als je een oud argument anhaalt dan verval je in herhaling. Je hebt het maar moeilijk met het verzinnen van flauwekul uitvluchten niet ?
En dat je niet weet wat thema zijn zegt wel genoeg.
En Adobe presenter is gewoon een tool dat gebruikt maakt van Microsoft powerpoint en het microsoft powerpoint formaat. Dus Adope presenter themes zijn hetzelfde als powerpoint themes
Create en Edit themes

  • -2 / 2

ArjenB op Zaterdag 5 April 2008 16:31

image

Het vervelende is dat je elke keer met dezelfde argumenten komt, anderen weerleggen ze, bij de volgende keer kom je met dezelfde ongewijzigde redenaties en mogen de eerdere reacties weer van stal worden gehaald. Als sociaal experiment heel aardig, gewoon, om uit vinden wie het het langst volhoudt, maar vanuit niet-experimenteel standpunt bekeken nogal voorspelbaar. En ronduit vervelend.

Wou je glyph-orientation er nog een keertje bij halen?

  • 3 / 3

baseline op Maandag 7 April 2008 14:08

image

Wou je glyph-orientation er nog een keertje bij halen?

Uit de ODF testsuite van de Opendocument fellowship
ODF Spec is not clear enough: verticalGlyphOrientation

Bron

Maar je zult het wel beter weten

  • -2 / 2

ArjenB op Maandag 7 April 2008 14:54

image

De vraag "Wou je glyph-orientation er nog een keer erbij halen?" was een uiting van mijn frustratie met jouw manier van discussieren, en was sarcastisch bedoeld. Je hebt de vervelende gewoonte om op een hoofdonderwerp te beginnen - was het een goed idee van Microsoft om te proberen de eigen MS-Office-XML te verheffen tot standaard Open Office XML - en vervolgens je te verliezen in detail-kwesties.

Zoals glyph-orientation.

Dat er punten, komma's en mogelijk hele paragrafen niet deugen aan ODF gaat net zo erg op voor OOXML, waarschijnlijk erger al is het alleen omdat de specificatie voor OOXML zoveel dikker is dan die voor ODF.

Microsoft heeft bij mij altijd de indruk gewekt dat ze niet in ODF stapten omdat ODF hun feitelijke monopolie op de Office-markt in gevaar brengt. Zie ook de verklaring van Bill Gates uit 2002 dat MS bewust koos voor "splendid isolation".

http://webwereld.nl/comments/50528/openxml-geaccepteerd-als-iso-standaard.html#comment_309422

Verder het al eerder gememoreerde gebrek aan belangstelling voor deelname aan ODF: als MS werkelijk pogingen had gedaan om in te stappen bij ODF was dat al lang en breed uitgemeten in de pers.

Ik maak in mijn directe omgeving regelmatig mee dat er compatibilteitsproblemen zijn tussen gebruikers van verschillende generaties MS-Office, en het valt me op dat de oplossing vaak ligt in downloaden van de laatste versie van OpenOffice, omdat die, ondanks de ellende van reverse-engineering, vaak beter omgaat met te oude of te nieuwe opmaak van MS-Office-bestanden dan de verschillende versies van MS-Office zelf. Ik vind het kolderiek dat vanuit MS-hoek backwards-compatibiliy als argument van stal wordt gehaald tegen ODF, als MS daar zelf een broertje dood aan lijkt te hebben.

Blijf vooral ingaan op de punten en komma's, dan leid je de aandacht er nog een beetje van af dat de enige bestaansreden van OOXML de bescherming van Microsofts marktpositie is. En dat de reputatie van een vroeger algemeen gerespecteeerd orgaan als ISO ernstig beschadigd is.

  • 1 / 1

ArjenB op Maandag 7 April 2008 14:57

image

En inderdaad, je wou glyph-orientation er weer bijhalen. QED :-(

  • 2 / 2

baseline op Maandag 7 April 2008 16:16

image

Nee ik wou eerder aangeven dat wat jij en Bolleke schijnen te beschouwen als een gigantische belangrijke discussie overwinning van hoe de ODF specificatie toch zo goed blijkt te zijn terwijl het een item dat zelfs voor vervente supporters van ODF die een testsuite voor ODF gebouwd hebben niet duidelijk is. Het is opvallend dat jij dit punt weer naar voren haalt.

Dat het uiteindelijk telkens over details gaat is omdat je discussierende collega's Bolleke en toiletpaper bij het minste of geringste argument vragen om voorbeelden en bewijsvoering. En dan altijd als je 5 voorbeelden noemt er vier negeren of als onbelangrijk kwalificeren en dan op 1 puntje proberen te scoren in de discussie. En precies dat puntje dan telkens weer naar voren proberen te brengen zoals jij nu ook doet.




  • -2 / 2

ArjenB op Maandag 7 April 2008 17:00

image

Dit zijn voor mij de redenen waarom de ISO-certificatie van OOXML mij met afgrijzen vervult:

- er is op oneigenlijke gronden voor een fasttrack procedure gekozen, gelet op de vloedgolf aan wijzigingen die het oorspronkelijke OOXML-voorstel opriep: fasttrack zou bestemd moeten zijn voor gerijpte voorstellen
- de behandeling van 2500 bladzijden met 1100 wijzigingen op een specificatie van 6000 bladzijden in het oorspronkelijke OOXML-voorstel was overhaast en maakte een farce van de BRM
- ik heb ernstige twijfels over de manier waarop in de verschillende nationale organisaties besloten is over OOXML

Ik heb belangstelling voor het beheer van standaarden, en ik volg de ontwikkelingen rond OOXML met verbijstering. Als de gevolgde manier van besluitvorming gemeengoed wordt bij ISO
kunnen we uitzien naar ISO-standaarden die het papier niet waard zijn waar ze op gedrukt zijn. Het aannemen van OOXML als ISO-standaard is in het belang van Microsoft, maar de manier waarop dat lijkt te gebeuren is, ik herhaal het maar, funest voor het aanzien van ISO en daarmee voor het aanzien van alle ISO-standaarden.

Patrick Durusau heeft gezegd dat ODF verliest als OOXML niet als ISO-standaard geaccepteerd wordt. Hij heeft misschien gelijk, maar ik denk dat dat niet opweegt tegen de beschadiging van ISO die het gevolg is van deze treurige geschiedenis. Om deze nog maar eens te herhalen: Microsoft zorgt ervoor dat je Flight Simulator kunt spelen op je pc, (ISO-)standaarden zorgen er voor dat je, als je een chartervlucht naar Ibiza neemt, je waarschijnlijk levend aankomt.

  • 2 / 2

baseline op Maandag 7 April 2008 23:04

image

Toen Sun en IBM een jaar of twee geleden lid zijn geworden van allerlei nationale ISO committees die moesten beslissen over de ODF PAS standardisatie had je toen ook als het gevoel dat het ISO proces daarmee negatief beinvloed werd of was het oten wel prima omdat het ODF betrof waarover beslist moest worden.

  • -2 / 2

toiletpaper op Maandag 7 April 2008 23:12

image

Dit is gezegd door MS, en de EU ondezoekt dat. Ik bend aar erg blij om. Ik vind dat wanneer er op grote schaal dit soort onregelmatigheden hebben plaatsgevonden, de standaard ook om die reden niet de zorgvuldigheid heeft ondergaan die een standaard die zo belangrijk is verdient.

Heel goed dat dit onderzocht wordt, en misschien heeft het wel gevolgen voor de status van OOXML binnen Europa. Het is toch een grote schande dat indien Sun en IBM de boel hebben lopen verzieken, dat daardoor deze standaard verkracht is.

MS verdient een goede en eerlijke ISO procesgang, en dus vind ik dat het allemaal opnieuw moet.

  • 2 / 2

toiletpaper op Maandag 7 April 2008 23:17

image

Samengevat: Het ISO proces moet onmiddellijk worden gestopt totdat alle bescshuldigingen van alle partijen zijn onderzocht. en als dan blijkt dat de standaard om welke reden dan ook, onzorgvuldig gecertificeerd is, moet dit opnieuw worden gedaan.

We kunnen een belangrijke en innovatieve ICT-partner toch niet in de kou laten met een onzorgvuldig behandelde standaard.

Ook die fasttrack, dat ze dat MS in de maag gesplitst hebben. Iedereen kan toch zien dat je geen 6000 pagina's in een paar maanden kunt behandelen, dat blijkt ook uit de 800 issues die zijn afgehamerd. Ook hier verdient MS een zorgvuldige benadering, en dient de standaard opnieuw te worden behandeld, amar dan zorgvuldig, in een normale ISO procedure. MS verdient dat!!

  • 1 / 3

ArjenB op Dinsdag 8 April 2008 09:07

image

Twee jaar geleden had ik het veel te druk met heel andere dingen. De gang van zaken rond OOXML heeft me wel aan het denken gezet, en het is wellicht een goed idee om het geval ODF ook nauwgezet te bekijken.

Waar MS in elk geval in de fout is gegaan is dat ze in het geval OOXML de zaak zo openlijk hebben belazerd. Dat was gewoon dom, want dan trek je de aandacht.

  • 2 / 2

Bolleke op Maandag 7 April 2008 20:48

image zomerhack badge 3

Uit de ODF testsuite van de Opendocument fellowship
ODF Spec is not clear enough: verticalGlyphOrientation

Bron

Maar je zult het wel beter weten
Tja, ik zie niet in waarom in dit voorbeeld "auto" een andere weergave dan "0" zou moeten geven. Misschien hebben ze het zelf ook niet helemaal begrepen?
Ik kan zo snel niet vinden waar ik in OpenOffice.org Writer de algemene verticale tekst-orientatie kan aanpassen. Misschien kan het ook wel helemaal niet, wat me eigenlijk niks zou verbazen aangezien het een tekstverwerker is, geen DTP-pakket. Ook dit heb ik je echter al eens uitgelegd.

  • 1 / 1

Bolleke op Zaterdag 5 April 2008 16:50

image zomerhack badge 3

Goh, al je een nieuw argument aanbrengt dan raken je argumenten op en als je een oud argument anhaalt dan verval je in herhaling. Je hebt het maar moeilijk met het verzinnen van flauwekul uitvluchten niet ?
Ik heb hier meerdere malen gevraagd om een paar goede voorbeelden van waarom ODF /per definitie niet compatible zou zijn met bestaande Office-documenten/. Vervolgens kom je met allerlei nieuwe functionaliteit aanzetten. Dat was de discussie dus niet.

En dat je niet weet wat thema zijn zegt wel genoeg.
Que? Ik weet ook niet alles, hoor. Zoals jij het uitlegt zijn "thema's" een soort stylesheets. Nou, dat is me even vernieuwend, zeg.
Overigens mijd ik Powerpoint en vergelijkbare presentatiepakketten als de pest. Ik heb er een hekel aan. Dus nee, dat wist ik inderdaad niet.
Maar wat ik er zo van lees is Presenter een Adobe-plugin en horen die Themes daar ook bij. Ook werkt het, zoals ik het lees, op de "oude" binaire .ppt formaten. Dus wat je nou probeert te bewijzen ontgaat me echt. Je wilt impliceren dat het bestaan van een plugin voor Powerpoint de reden is dat het werkelijk waar onmogelijk is voor MS om ODF te implementeren?

  • 4 / 4

baseline op Zondag 6 April 2008 20:32

image

Het is echter wel iets wat ODF niet ondersteunt.
Zoals ODF graphisch sowieso technisch zwaar achterligt en nog in de vorige eeuw verkeert.
ODF ondersteunt graphisch ook maar een subsetje van SVG terwijl OOXML een uitgebreide graphische ondersteuning biedt

Zie bijvoorbeedl eens:
Technical analysis between DrawingML and SVG.zip

  • -2 / 2

Bolleke op Zondag 6 April 2008 20:44

image zomerhack badge 3

Ik vind dit niet zo interessant - het gaat over SVG, niet ODF. Sowieso is een kantoorapplicatie geen tekenprogramma, maar dat heb ik je ook al vaker uitgelegd.

Wat ik echt prachtig vind, nu ik even door je documentje blader, is dat DrawingML support biedt voor audio files. WTF doet geluid in een graphics-formaat???

  • 3 / 3

toiletpaper op Zondag 6 April 2008 20:54

image

dank voor je opoffering, je had je berichtje al geplaatst toen ik het aan het typen was

  • 1 / 1

Bolleke op Maandag 7 April 2008 07:47

image zomerhack badge 3

@toiletpapier: NP, ik doe het graag. Kost gemiddeld ook maar een paar minuten om zo'n soort "rapport" neer te sabelen.
Leuk detail: het is een ZIPje met daarin een PDF en een Word-versie. Kennelijk vertrouwen ze er niet zo op dat hun superstandaard OOXML al brede support heeft! (Overigens is PDF de juiste keuze voor dit soort documenten, daar is het voor bedoeld nl.)

  • 3 / 3

baseline op Maandag 7 April 2008 13:36

image

Sorry, wat sabel je eigenlijk neer ? Je vind het niet zo interessant. Tja, lekker boeiend als we alleen ODF vergelijken op punten die jij boeiend vind.
Het rapportje toont duidelijk aan dat DrawingML tientallen, zo niet honderden features biedt die SVG niet bevat.
En ODF gebruikt dan zelfs nog maar een subset van SVG aangevuld met OOo specifieke 3d en object embedding features.

En dan je aparte opmerking over geluidsondersteuning. ODF biedt namelijk ook geluidsondersteuning. ODF biedt geluidsondersteuning (sounds) echter specifiek aan in de presentations markup (of alternatief via embedded SMIL of via andere embedded object methoden waarmee je eigenlijk in theorie alles kan embedden).

OOXML biedt geluidsondersteuning aan in de drawingml markup zodat de geluidseffecten niet beperkt zijn tot presentations zoals in ODF. Zo kun je dus ook geluidseffecten hangen aan knoppen of geanimeerde objecten in andere documenten dan presentaties. Multimedia en office documenten zijn lang niet zo verschillend meer. Bijvoorbeeld documenten die een tekst zowel in geschreven tekst als in gespoken vorm bevatten zijn steeds meer in opkomst.

  • -2 / 2

Bolleke op Maandag 7 April 2008 20:33

image zomerhack badge 3

Tja, lekker boeiend als we alleen ODF vergelijken op punten die jij boeiend vind.
Het rapportje toont duidelijk aan dat DrawingML tientallen, zo niet honderden features biedt die SVG niet bevat.
Ook hier zeg je het zelf al: dat ging over SVG. SVG != ODF. Ik ga toch niet HTML bekritiseren omdat ik CSS misschien slecht vind? Ook al werken ze samen, het zijn losstaande zaken.

Kortom: in een discussie over ODF vs. OOXML vind ik de kwaliteit van SVG niet interessant, nee. Net zoals in dezelfde discussie de kwaliteit van Excel (een implementatie van een deel van OOXML) niet interessant zou moeten zijn (ware het niet dat... enfin).

  • 2 / 2

baseline op Maandag 7 April 2008 22:58

image

Toch wordt OOXML bekritiseerd omdat het geen SVG toepast en ODF geprezen terwijl het een soort hotseklots SVG compatible implementatie heeft (die eigenlijk niet echt compatible is) aangevuld met allerlei OpenOffice draw elementen.

  • -2 / 2

Bolleke op Maandag 7 April 2008 20:37

image zomerhack badge 3

Bijvoorbeeld documenten die een tekst zowel in geschreven tekst als in gespoken vorm bevatten zijn steeds meer in opkomst.
Jawel, maar dan is het dus geen /tekst/document meer. Als dat het doel was had men beter aan elke paragraaf een alternate-attribuut kunnen toevoegen (bijvoorbeeld).

Pseudo-code:

<p alt:sound="files/spoken-p1.wav" alt:img="files/icon-p1.png">Lorem ipsum dolor sic amet</p>

Als je alternatieven aan een tekstdocument wilt toevoegen, kortom, lijkt een spec die /drawing/ML heet een verdomd slechte keuze.

Maar daar mogen we het uiteraard over oneens zijn.

  • 2 / 2

baseline op Maandag 7 April 2008 08:00

image

Wat doen OLE objecten, Java applets en plugins(?) in een graphics formaat (ODF) ?
<ref name="draw-object-ole"/>
<ref name="draw-applet"/>
<ref name="draw-plugin"/>

  • -2 / 2

toiletpaper op Maandag 7 April 2008 09:25

image

Ze bieden de mogelijkheid om OLE-links op te nemen, ik neem aan dat OOXML ook nog steeds OLE kent?
Want als het dat niet kent, dat zou pas echt een breuk met het verleden zijn, en OOXML absoluut onbruikbaar maken.

Een OLE link biedt de mogelijkheid een om een object te openen met een andere applicatie, end aarmee te bewerken. Het komt vaak voor dat mensen dit willen. Veel mensen willen meer functionaliteit dan een tekstverwerker intern heeft om, bijvoorbeeld, een grafisch object te bewerken. Dat is toch een deel van het eieren eten van OLE.
Verder biedt OLE de mogelijkheid om te linken naar een extern/elders opgeslagen entiteit, wat soms ook handig kan zijn, bijvoorbeeld, een grafisch object op een shared directory, bijvoorbeeld, een bedrijfslogo, of een grafiek die aan verandering onderhevig is, en een document dat de noodzaak heeft om actueel te zijn, of verzin zelf een goede reden.

Ik vind het een beetje raar dat jij dit allemaal niet weet.

  • 2 / 2

Bolleke op Maandag 7 April 2008 11:55

image zomerhack badge 3

Ik vind het een beetje raar dat jij dit allemaal niet weet.
Ik vind dat zelf inmiddels niet zo heel raar meer ;-)

  • 3 / 3

baseline op Maandag 7 April 2008 13:18

image

Misschien mioet je beter opletten waar het over gaat.
Bolleke vindt het gek dat de graphiche markup van OOXML ondersteuning voor geluidsfiles bevat (iets wat in ODF in de presentation markup zit). Maar waar ik een combinatie van multimedia effecten nog wel zie is het is toch veel vreemder dat in ODF de embedding van bijvoorbeeld OLE objecten, java applets en plugin (en nog een aantal andere objecten) in de graphics markup van ODF zitten. en dat nog afgezien van het feit dat plugins verder niet gedefinieerd zijn en dat dus ook best java applets of ole objecten zouden kunnen zijn.
Al deze embedding methoden in de graphics markup is echter werf niet zo gek als je beseft dat de draw graphics objecten in ODF gewoon vrijel 1-op-1 OpenOffice code is en dat dus alle methoden die in OOo gebruikt worden voor het embedden van objecten in graphics draw objecten zijn gestopt.

Dat je OLE kunt linken in ODF vind ik niet gek. Dat kun je in OOXML ook.
Dat ODF daar een aparte methode voor heeft gestopt in een graphics module vind ik wel apart. Dat is namelijk een typische legacy OOo feature. Maar ODF was toch helemaal niet van de legacy features...


Objecten bevat ODF iets van 8 of 10 methoden om objecten te embedden. Hier duidelijk geen generieke oplossingen.

  • -2 / 2

toiletpaper op Maandag 7 April 2008 19:56

image

Objecten bevat ODF iets van 8 of 10 methoden om objecten te embedden. Hier duidelijk geen generieke oplossingen.
ODF staat wat meer multi-platform, OOXML is toch vooral een Word successor, vandaar java in ODF en niet in OOXML. verder vind ik het niet zo gek, de mogelijkheid tot object embedding, het gaat om een techniek die, pakweg, 15 jaar geleden is ingezet.

  • 1 / 1

toiletpaper op Maandag 7 April 2008 19:59

image

Dat OOXML alleen OLE embedding toestaat geeft aan dat het formaat niet multi-platform is, want OLE werkt alleen op Windows, dus eigenlijk wel een forse tekortkoming voor OOXML.

  • 1 / 1

baseline op Maandag 7 April 2008 22:48

image

Dat OOXML alleen OLE embedding toestaat bedenk je nu net zelf ?
Dat is namelijk niet zo

  • -2 / 2

toiletpaper op Maandag 7 April 2008 23:07

image

verklaar je nader, welke soorten embedding zijn nog meer mogelijk?

  • 1 / 1

Bolleke op Maandag 7 April 2008 20:30

image zomerhack badge 3

Wat wil je nou eigenlijk bewijzen?
Bolleke vindt het gek dat de graphiche markup van OOXML ondersteuning voor geluidsfiles bevat (iets wat in ODF in de presentation markup zit).
Ja, en dat is precies waar het hoort.

  • 2 / 2

baseline op Maandag 7 April 2008 22:50

image

Je bedoelt net als het embedden van plugin, applets en ole links in de graphics module thuishoort ?
Want zoals ODF het doet is altijd geweldig natuurlijk

  • -2 / 2

toiletpaper op Maandag 7 April 2008 23:08

image

ik zie niet in waarom dit een probleem is?

  • 1 / 1

Bolleke op Dinsdag 8 April 2008 07:13

image zomerhack badge 3

Want zoals ODF het doet is altijd geweldig natuurlijk
Dat zeg ik helemaal niet en dat weet je best. De discussie gaat over het volgende: kun je ODF uitbreiden met zaken die er niet inzitten maar waarvan je wel vindt dat dat zou moeten, of is het inherent incompatibel met MS Office en is een 2e standaard noodzakelijk?

MS beweert bij hoog en bij laag dat laatste, en ik betwijfel dat nog altijd sterk. Voornamelijk omdat het erg lastig blijkt te zijn om aan te geven waarin dat hem dan precies zou moeten zitten. Je beste kanshebbers zijn tot nu toe zeer nieuwe features gebleken, terwijl het punt juist was dat het om legacy-documenten ging (waarbij nieuwe features dus geen rol zouden moeten spelen). (Dit nog even los van de discussie of het voor legacy-documenten niet juist gewenst is dat je legacy-formaten gebruikt.)

Ergo: MS voegt weer een zootje nieuwe dingen toe, verkoopt het onder het mom van legacy-support en we zitten weer lekker vast in een nieuwe vendor-lockin, want de concurrentie staat wederom op achterstand.

Q.E.D.

  • 2 / 2

toiletpaper op Zondag 6 April 2008 20:48

image

Zullen we zeggen dat die site net zo onafhankelijk is als bijvoorbeeld Groklaw? (daar mopper jij altijd over als iemand iets van daar citeert)

Ik heb geen tijd om al die marketing gestuurde rapporten van MS te lezen, spijt me, aan mij gaat je boodschap voorbij. Misschien dat Bolleke zich opoffert.
:

whois openxmldeveloper.org

Registrant Name:Domain Administrator
Registrant Organization:Microsoft Corporation
Registrant Street1:One Microsoft Way
Registrant Street2:
Registrant Street3:
Registrant City:Redmond
.......
Admin Name:Domain Administrator
Admin Organization:Microsoft Corporation
Admin Street1:One Microsoft Way
Admin Street2:
Admin Street3:
Admin City:Redmond
Admin State/Province:WA
.......
Tech Name:MSN Hostmaster
Tech Organization:Microsoft Corporation
Tech Street1:One Microsoft Way
Tech Street2:
Tech Street3:
Tech City:Redmond

  • 2 / 2

baseline op Vrijdag 11 April 2008 17:55

image

De geciteerde informatie is geen nieuws of opinie maar een link naar een technische vergelijkingsanalyse.
Vermoedelijk gemaakt naar aanleiding van vragen waarom OOXML geen bestaande SVG functionaliteit hergebruikt maar DrawingML gebruikt. De analyse toont dat heel veel van de DrawingML features gewoon niet ondersteunt worden in SVG.

En je kunt de waarde ervan zelf controleren.
De specs van SVG en DrawingML zijn namelijk publiek in te zien.

Als deze technische analyse info van OpenXMLdeveloper site zo onbetrouwbaar zou zijn dan hadden de anti OOXML'ers er flink mee kunnen scoren .

  • -2 / 2

edjez op Vrijdag 4 April 2008 21:20

image

want over vijf jaar weet niemand meer wat Word is
Als ik me de negatieve reactie na uitkomen van SP3 voor Office herinner, speciaal met betrekking tot het niet meer ondersteunen van documenttypen ouder dan 14 jaar, denk ik dat we voorlopig niet van het DOC-formaat af zijn.

  • 2 / 2

Diogenes_Isher op Zaterdag 5 April 2008 09:22

image

De titel van dit WebWereld-artikel luidt : " Welkom in de 'Nieuwe Wereld van Documenten' ".
Had het niet moeten luiden: "Welkom in de 'Heerlijke Nieuwe Wereld van ms-only Documenten' " ? (Zoiets als in het boek "Brave New World" van Aldous Huxley ?)
Want daar komt het volgens mij, na zowat alle reacties hier te hebben gelezen, toch gewoon op neer ? De ms-vendor-lockin in "optima forma", waarbij ms alle in "hun" nu ja, "format" gemaakte/opgeslagen documenten/data gewoon in gijzeling houdt, nietwaar ?
Alleen om die zeer eenvoudige reden ben ik onvoorwaardelijk tegen een ms-o(nly)oxml ISO-"standaard" die duidelijk slechts ten doel heeft deze misdaad van het totaal in gijzeling houden van informatie van anderen (zelfs van regeringen !) voor te laten duren - en bovendien is daar een wereld-wijde standaard ook absoluut niet (dat is: nooit) voor bedoeld geweest !

Het lijkt mij dat zelfs ms nu begint de bui te zien aankomen, want waarom zou er anders een of andere bobo van ms tegenwoordig vrij vaak (zelfs steeds vaker) hier op het WebWereld-forum (al dan niet met z'n voeten op de tafel) zijn pr/reclame/fud-praatjes afsteken ? En, God betere het, van de geachte redactie er zelfs een hele "column" over hebben mogen schrijven ?
Gaat WebWereld, omwille van correcte, evenwichtige en bovenal onpartijdige verslaggeving nu ook zeer binnenkort een belangrijke voorstander/vertegenwoordiger van ODF een column laten schrijven ? Dat hoop ik van wel...
Omdat WebWereld anders de schijn op zich zou kunnen laden, aan 1-zijdige "verslaggeving" te doen, dwz. zonder beide partijen in deze zaak een forum (dwz. column) voor hun mening te bieden - wat een absolute doodszonde is in het land der (onpartijdige, geloofwaardige) journalistiek ! Alle "made in Redmond"-berichtjes, die kennen wij zowat allemaal al bijna uit ons hoofd, helaas...
Ter verklaring: ooit was ik een freelance oorlogs-correspondent/waarnemer (o.a. tijdens Desert Storm "mark 1"), dus van (oorlogs)verslaggeving weet ik echt wel iets af... Vooral dat zodra er geschoten wordt je direct moet wegduiken in dekking, of eigenlijk liever zelfs nog ietsje eerder. Kogels e.d. proberen terug-koppen is namelijk een tak van sport die, denk ik, mij niet erg ligt... ;-)
(Jawel, door zelfs in die afschuwelijk omstandigheden toch mijn gevoel voor humor te behouden, heb ik mijzelf en (voor zover al aanwezig) mijn gezonde verstand weten te behouden. Mijn aanvankelijke naiviteit die ben ik wel helemaal kwijt en dat is maar goed ook !).

Omdat ik ook alweer heel wat jaartjes meedoe aan het WebWereld-forum, lekker in het toch zeer comfortabele en veilige Nederland via mijn Linux-bak, weet ik "as a fact" dat "hoge" (of wat er voor door wil gaan) bobo's van een firma die zich "verwaardigen" hier met ons in discussie (ook wat er voor door wil gaan ;-) ) te treden, enkele jaren geleden nooit maar dan ook echt nooit werd vertoond...
Wat het al met al natuurlijk wel veel interessanter maakt, om de doods-strijd van de laatste grote hyper-praedatore dinosaurus van nabij te mogen aanschouwen. Maar niet van al te nabij, AUB...?
Omdat als het monster uiteindelijk dood gaat (en dat doet het gegarandeerd, op een uitzonderlijk goede dag, let maar op), het kadaver dan wel eens bovenop onze hoofden neer zou kunnen ploffen en dat lijkt mij ongewenst. :lol:

Maar even alle gekheid op een stokje: dat hele ms-ooxml is helemaal geen echte standaard, maar de zoveelste poging van ms om hun monopolistische macht te behouden - en dat ook nog tegen beter weten in. Indien de meerderheid der ICT-ers en anderen (zoals managers, politici en natuurlijk gewone huis, tuin en keuken PC-gebruikers) dat nu eens in zouden (willen) zien...

Dit nog: het geven van minnetjes is tegenwoordig een totaal zinloos tijdverdrijf, een betekenisloos afreageren zonder enig effect, omdat berichtjes toch niet meer dichtgeklapt worden bij -3. Men kan het dus beter achterwege laten een een leuker, opbouwender tijdverdrijf proberen te verzinnen...

  • 3 / 3

Scheurleer op Zaterdag 5 April 2008 11:00

image

Correspondent. Eh...vraagje. Moeten die niet altijd kort en bondig schrijven :-) ? Maar ik moet zeggen dat ik je stukjes met plezier lees, ondanks de vele bijzinnen die je gebruikt en zijpaden die je inslaat. Dit keer echter ben ik het met een zinsnede niet eens.

Maar even alle gekheid op een stokje: dat hele ms-ooxml is helemaal geen echte standaard

Helaas heeft ISO in haar wijsheid besloten om dit wel als een standaard uit te roepen, met die situatie zitten we opgescheept (met we bedoel ik in dit geval de ICT gemeenschap). Op tal van terreinen (opslag van documenten, uitwisseling van informatie, koppeling met bestaande of nieuw op te zetten architecturen, denk ook aan GOUD) dwingt het overheden, informatie-architecten, managers tot het maken van keuzes. Dit was niet nodig geweest.

  • 3 / 3

Diogenes_Isher op Zaterdag 5 April 2008 11:21

image

@ Scheurleer 05-04-2008 11:00
Waar u, helaas, nog gelijk in heeft ook... Wat ik eigenlijk had moeten schrijven is: het feit dat ms de ISO gemanipuleerd heeft ms-o(nly)oxml tot "standard" te verheffen, nog lang niet betekent dat het dit ook echt is .
Want wat nu, als heel de wereld (behalve ms dan) ODF gebruikt en (heel verstandig) heel dat ms-o(nly)oxml laat voor wat het is en het helemaal niet gebruikt ?
De ISO is gelukkig niet absoluut oppermachtig - en ms nog veel minder - omdat als de wereld een z.g. "standard" gewoon niet accepteert en dus niet gebruikt, die "standard" daardoor ook niets meer betekent. Toch ?

  • 2 / 2

Scheurleer op Zaterdag 5 April 2008 12:58

image

Mee eens. De situatie is echter ook zo dat er wereldwijd zo'n 450 miljoen Office gebruikers zijn (bron: Hans Bos in zijn artikel). Die zijn waarschijnlijk net zo divers als de mensen die op dit forum discussie voeren. Dus helaas zijn we voorlopig nog niet van MS Office, OOXML en meer van die goedbedoelde producten af.

  • 3 / 3

Diogenes_Isher op Zaterdag 5 April 2008 12:10

image

O, aangaande dat correspondent zijn, ja, daar heeft u inderdaad volstrekt gelijk in dat toen mijn berichtjes veel korter waren dan die hier op WebWereld. Misschien dat ik hier een beetje compenseer voor wat ik toen wilde schrijven, maar niet kon omdat tijdens b.v. een luchtaanval de grond af en toe letterlijk schudt en soms zelfs complete plafond-delen naar beneden komen, als bij een flinke aardbeving. En dat schrijft best vrij lastig, als je je laptopje en jezelf voortdurend vast moet houden ter voorkoming dat beide tegen de grond slaan. Dan heb ik het nog lang niet over een voltreffer op je hotel - want dan schrijf je nog maar 3 letters: "KIA"* - maar over hele zware bommen die enkele 100-den meters verderop vallen... Geluk voor ons in dat hotel dat die piloten goed konden mikken, want anders had u nu dit berichtje niet kunnen en hoeven te lezen...
Ooit zelf een flinke aardbeving meegemaakt ? ik wel, in Indonesie, tijdens mijn wereldreis. Heel boeiend en angstaanjagend, dus niet geschikt voor mensen met zwakke zenuwen. ;-)
Dat freelance-correspondent zijn was niet zo'n bijster goed idee van mij, beter voor de gezondheid om het niet na te volgen... Zo is mijn gehoor door die ontploffingen blijvend licht beschadigd geraakt, ik ook altijd met mijn verrekte nieuwsgierigheid !
Maar, mazzel dat had ik toen verder wel en hoe, daarom ben ik er nog...

*KIA=Killed In Action, US-Army-lingo wat al snel ook door correspondents gebruikt werd.

  • 1 / 1

Scheurleer op Zaterdag 5 April 2008 13:18

image

Drie letters, KIA. Hé, ISO heeft ook drie letters. Het zal toch niet........:-)

  • 2 / 2

Diogenes_Isher op Zaterdag 5 April 2008 22:04

image

Ja, inderdaad, dat is een leuke... U kent ook vast wel de betekenis in 't Engels van de term "3 and 4 letter words..." ;-)

  • 1 / 1

dada1958 op Zondag 6 April 2008 09:50

image

EC onderzoekt ooxml-standaardisatie

  • 3 / 3

Scheurleer op Zondag 6 April 2008 11:03

image

Dank je voor de link. hartstikke goed. (NB. Het bericht op Businessweek is wat uitgebreider dan van Tweakers.). Even een alinea uit het bericht van Businessweek.

In a letter seen by silicon.com sister site CNET News.com, European regulators raised queries with the national standards body in Norway to gain details into the local standardisation process. Specifically, the Commission sought information on attempts to influence the debate or vote over the standards proposal.

[offtopic]
Wat ik jammer vind is dat de Europese Comissie geen bevoegdheden heeft om het hele proces bij ISO onder de loep te nemen. Ze gaat alleen over Europese aangelegenheden. In tal van discussies op dit forum hebben Baseline en Toiletpaper aangegeven dat bij de stemming over OOXML landen aanwezig zijn geweest, die zich normaliter niet erg roeren (o.a. uit Afrika). Wat ik me dan afvraag is: is dan niemand bij ISO op het idee gekomen dat het toch wel erg vreemd is dat dit soort landen zich ineens heel duidelijk manifesteren?
[/offtopic]

Maar, eerlijk gezegd, ik ben blij dat het deze aandacht heeft. Niet zozeer om OOXML 'op te blazen', maar wel om de integriteit van ISO als organisatie te waarborgen (het zou wat zijn als zou blijken dat ISO gezwicht is voor het geld).

  • 4 / 4

toiletpaper op Zondag 6 April 2008 13:41

image

Zelfs Microsfot geeft toe dat er sprake is van grove onregelmatigheden gepleegd door Google en IBM (who else). Maar dan is er zoveel reden te meer om deze standaard af te blazen. Alle partijen klagen over onregelmatigheden. Bedrijven, landen committee's, er is werkelijk geen reden om dit standaardisatie-proces als geslaagd te noemen. Een aanfluiting is het.

Dus, afblazen en opnieuw beginnen, dat is mijn advies.

  • 3 / 3

baseline op Zondag 6 April 2008 16:31

image

Het geluid van de verliezers.
86% stemt gewoon voor de standaard en de verliezers vinden dat het moet worden afgeblazen en overgedaan.
Heel zielige verliezers denk ik dan

  • -2 / 2

ArjenB op Zondag 6 April 2008 17:13

image

ISO is hier de grote verliezer.

  • 3 / 3

toiletpaper op Zondag 6 April 2008 20:53

image

Ik reageer op MS, die zegt dat het proces door toedoen van IBM en Google onzorgvuldig is verlopen.

Ik neem aan dat MS wil dat de standaard boven iedere twijfel is verheven, en nu komen ze met kritiek op de ISO-processen naar buiten. Dus, ik zou zeggen, trek je conclusies.

Het gaat bij standaarden niet over winnen of verliezen, in die termen praat jij al maanden, maar eienlijk hoort dat geen rol te spelen. Het gaat over een gezamenlijke inspanning om de wereld te voorzien in een goede standaard. Ook daar is in gefaald, al in een vroeg stadium.

Alle redenen om het opnieuw te doen, wat om nou de successor van MS Word ISO status te geven, tja, ik ben het dan met ArjenB eens, ISO is duidelijk de grote verliezer, en met ISO, wij allemaal, ook jij baseline, al ontbreekt het jou blijkbaar aan visie om dit te kunnen inzien.

  • 2 / 2

Diogenes_Isher op Zondag 6 April 2008 23:21

image

Toch is er ook iets heel goeds aan heel dit gedoe en aan alle discussies over die ms-o(nly)oxml "standard"...
Jazeker, dat meen ik serieus: namelijk dat lang niet meer alles wat ms (of een andere grote firma) ons (tegen een te veel hoge prijs) door de strot probeert de duwen ook zomaar kritiekloos geslikt wordt !
En door alle opschudding omtrent dit debacle kan dat alleen maar nog verder toenemen, zeker niet verminderen. En dat is hoe dan ook winst voor ons als comsumenten - al kan het wel eens (groot) verlies voor ms betekenen.
Waarbij ik nog even wil aantekenen dat ms geen enkel medelijden verdient, van niemand - zij hebben het hier zelf opzettelijk naar gemaakt door hun in de ICT volstrekt onhoudbare "doctrine" van "splendid isolation". Blijkbaar begrijpen zij bij ms niet waar de "C" in "ICT" voor staat - of veel waarschijnlijker: willen zij dat niet begrijpen...

Daarom zou, zolang er maar flink veel over gesproken/gediscussieerd wordt, heel dit ms-o(only)oxml-debacle (net als het vista-fiasco) wel eens de zoveelste nagel aan de doodkist van ms kunnen blijken te zijn... Dat is wel te hopen, omwille van de echte innovatie in de (ICT-) wereld als geheel.

Alleen al het feit dat zelfs een bug van ms "en passant" tot een ISO-standard verheven zou kunnen worden ! Als dit echt doorgaat, wat God verhoedde, dan is de ISO daarmee wel tot een heel laag niveau gezonken... Vooral omdat ms zelfs copyright schijnt te claimen op alle (uiterst tarijke en vaak ernstige) bugs in hun sof(t)warez...

Een standard die zwaar berust op "copyrighted" of "patented" zaken van slechts 1 enkele commercieele firma kan volgens mij per definitie nooit een echte standard zijn. Of wil men zo dadelijk ook de standards voor lengte, tijd, gewicht, enz. gaan verkwanselen aan de 1 of andere geld- en machts- bezeten firma ? Ter bevordering van de innovatie ?? Yeah, right...!

Door al dit gedoe, hoop ik intens, zal de ISO spoedig weer een instituut voor het registreren/documenteren/valideren/enz. van standards zijn - in plaats van een corrupt(able) clubje dat zich als een dom, log en onverschillig trek-os voor het karretje te laten spannen van de pr/reclame/fud (is verreweg de belangrijkste en grootste) afdeling van ms...

Volgens mij (=een dissclaimer) is ms niet eens een echte ICT-firma - maar een handels-onderneming die voornamelijk een bepaalde "image" (namelijk dat als je hun spullen gebruikt, je een hele stoere vent/meid bent) voor (onevenredig) veel geld verhuurt.
Jazeker: verhuurt - omdat de "gebruiker" volgens de eula van ms er nooit de eigenaar van kan en mag worden. Wie mij niet zomaar gelooft (=heel verstandig), die kan het zelf lezen in de ms-eula...
Net als bij al die andere overhyped-artikelen (zoals bepaalde merken sport-schoenen en kleding) die in feite technisch volslagen inferieur zijn, maar door mij onbekende redenen wel "in de mode" zijn geraakt. Mede daarom volg ik nooit de mode - en heb dat ook nooit gedaan - maar bepaald mijn product-keuze altijd uitsluitend op grond van een bewezen gunstige kwaliteit/prijs verhouding.

Volgens mij behoort een toch bij uitstek technisch product als een (besturings/office)-systeem gekozen te worden op grond van de technische kwaliteiten en natuurlijk de prijs, geboden service, uitwisselbaarheid en mogelijkheden het aan de eigen bedrijfs-eisen aan te passen - maar nooit op grond van wat er "in de mode" is...
Alleen al op grond van dit laatste, toch sterke en onweerlegbare argument van kwaliteit/prijs-verhouding, lijkt het mij puur zakelijk beschouwd hoogst onverstandig en zelf-schadend om ms-spul te huren/gebruiken.

Maar, gelukkig, in een democratie kan en mag men zich een eigen mening vormen en eigen besluiten nemen - zelfs als men zichzelf daarmee ernstig te kort doet. Al is het ook een onvervreembaar democratisch recht om anderen hier op te mogen wijzen, zelfs op een zeer spottende, satirische manier ! Waar ik dan ook, heel dankbaar, vaak gebruik van maak. ;-)

  • 2 / 2

toiletpaper op Woensdag 9 April 2008 11:14

image

Heb je eht gelezen, Hans Bos, diegenen die jou zwakzinnige OOXML verdedigen,s telen de office-pakketten onder je reet vandaan, zie
webwereld.nl/co...#comment_311190

Dat MS zich moet laten verdedigen door een stelletje gauwdieven

  • 1 / 1

baseline op Woensdag 9 April 2008 12:58

image

Als er iemand zwakzinnig is dan ben jij dat wel.
Doe normaal. Je lijkt wel een peuter.

  • -2 / 2

toiletpaper op Woensdag 9 April 2008 14:50

image

Als er iemand zwakzinnig is dan ben jij dat wel.
Sterk argument.

Maar waarom noem ik OOXML zwakzinnig?

Je zei volgende:
Het was geen fout in Excel maar een bewuste keuze om compatibel te blijven met Lotus 1-2-3 de dominante spreadsheet in het verleden.

Tja, ik interpreteer dat zo:

Excel leest een Lotus bestand, en interpreteert de bug zoals het hoort (volgens jou)
Excel schrijft een Excel bestand, waarom zou daar dan een bug in moeten zitten?
Waarom kan Excel niet als het Lotus leest of schrijft rekening houden met een bug, en als het Excel of ISO leest en schrijft daar geen rekening mee houden?

Je ziet toch wel dat je OOXML middels een Jip en Janneke argument legitimiteit probeert te geven.

  • 2 / 2

baseline op Woensdag 9 April 2008 23:48

image

Het tekent dat je niet veel van spreadsheets begrijpt.
Een decimaal datumveld kan heel goed een formule bevatten om de decimale waarde vast te stellen. De inhoud van het datumveld staat dan dus niet vast voor een implementatie.
Als je een ander formaat voor decimale datums gaat toepassen dan kan de door de formule gegenereerde waarde wel eens een ander resultaat geven.
ODF heeft dat opgelost door voor compatibliteit een formaat te gebruiken met startdatum 31-12-1899. Dat is precies hetzelfde als het decimale date1900 formaat vanaf 1-3-1900.
Zolang dus datumvelden met formules er in geen datums onder de 60 kunnen bevatten gaat dat goed. Bij normale datumreeksen levert dat zelden problemen op omdat die meestal niet zover teruggaan in de tijd. In tussenberekeningen met datumverschillen zijn dergelijke lage waarden in datum velden echter best mogelijk en dan is dus 100% compatibliteit niet meer aanwezig door het formaat dat ODF toepast.
Dat komt weliswaar niet vaak voor maar levert wel een mogelijk probleem op als je bijvoorbeeld officiele documenten gaat converteren of bedrijfkritische informatiestukken.
Door het date1900 formaat toe te blijven passen voor geconverteerde bestanden garandeer je 100% procent compatibiliteit. Door gebruik te maken van een daarop sterk gelijkend formaat heb je slechts een hoge mate van compatibiliteit.

  • -2 / 2

toiletpaper op Donderdag 10 April 2008 01:19

image

Jij gaat helemaal niet in op wat ik zeg, en ik ga het ook niet meer herhalen, daar heb ik geen tijd meer voor over.
Ik laat het hierbij, een verstandig lezer moet maar even terug lezen, en zien dat jij het over heel iets anders hebt.

Nogmaals heel kort, er zit een bug in het ISO OOXML formaat betreffend een schrikkeljaar, die bug is, zeg jij om compatibel te zijn met het oude Excel, dat weer compatibel wilde zijn met Lotus.

Volgens mij grote onzin, en ik heb uitgelegd waarom. Bestanden zijn niet compatibel, dat is Jip en Janneke taal

Excel leest een Lotus bestand, en interpreteert de bug zoals het hoort (volgens jou)
Excel schrijft een Excel bestand, waarom zou daar dan een bug in moeten zitten?
Waarom kan Excel niet als het Lotus leest of schrijft rekening houden met een bug, en als het Excel of ISO leest en schrijft daar geen rekening mee houden?

Klaar.

  • 2 / 2

toiletpaper op Donderdag 10 April 2008 08:58

image

Simpel is, in de huidig gepubliceerde spec van OOXML, downloaden op:
www.ecma-intern...ds/Ecma-376.htm
staat dat het jaar 1900 een schrikkeljaar is. (wat niet zo is, want jaartallen deelbaar door 100 zijn een uitzondering op de schrikkeljaar cyclus, behalve jaren deelbaar door 400)
Dit is een Excel-bug die gepromoot is naar ISO.
Het is gewoon een slordigheid in Excel.

Dit exporteren had eenvoudig voorkomen kunnen worden. Het bewijs daarvoor is ODF, OpenOffice kan zonder probleem Excel bestanden inlezen, en als ODF wegschrijven, ook als er datums in voorkomen waarbij deze Excel-bug van toepassing is. En daarna kan het ook weer de weg terug vervolgen.

Samengevat: het was niet nodig geweest om de Excel-bug te promoten naar ISO-OOXML. Dit is een een ernstig probleem, om een standaard die voor de wereld bedoeld is onnodig te belasten emt een Excel bug, die volgens jou een Lotus-bug is.

En de reden die wordt opgegeven is zwakzinnig, want slaat helemaal nergens op, ik heb het hierboven in blauw weergegeven, en dat het anders kan bewijst OpenOffice, maar blijkbaar zijn ze bij IBM en Sun slimmer dan bij Microsoft, want daar zijn ze in staat om een bug op te lossen die ze bij Microsoft om Jip en Janneke redenen laten zitten.
Maar bij Microsfot zijn ze goed in jatten, net als hun adepten, ze hadden gewoon de code van openoffice ter inspiratie kunnen gebruiken, want dat is open source, maar ook dat hebben ze nagelaten.

Er is maar een reden voor deze waanzin. Zoveel mogelijk drempels opwerpen voor concurrentie.

Iedere keer zijn er rechtszaken en miljarden boetes nodig om MS in het normale zakelijke gareel te houden, ook nu weer bij ISO. Het is goed dat er een onderzoek komt, alleen al om deze malversaties aan het licht te brengen

  • 2 / 2

baseline op Vrijdag 11 April 2008 07:56

image

Het bewijs daarvoor is ODF, OpenOffice kan zonder probleem Excel bestanden inlezen, en als ODF wegschrijven, ook als er datums in voorkomen waarbij deze Excel-bug van toepassing is.

Dat tekent slechts dat het een issue is wat in de door jou gebruikte bestanden niet voorkomt want OpenOffice kan dat zeker niet in alle gevallen correct wegschrijven in ODF.

  • -2 / 2

toiletpaper op Donderdag 10 April 2008 09:02

image

Zolang dus datumvelden met formules er in geen datums onder de 60 kunnen bevatten gaat dat goed. Bij normale datumreeksen levert dat zelden problemen op omdat die meestal niet zover teruggaan in de tijd.
Waarom niet intern de oude buggy rekenroutines aanhouden, maar wegschrijven naar een bestand dat wel schrikkeljaren goed doet (OpenOffice kan dat wel met Excel-bestanden), dat was een simpele oplossing. Het is gewoon op het zwakzinnige af, de redenatie die jij volgt.

  • 2 / 2

baseline op Donderdag 10 April 2008 11:02

image

Je begrijpt gewoon geen apenootje van spreadsheets formules.

maar wegschrijven naar een bestand dat wel schrikkeljaren goed doet (OpenOffice kan dat wel met Excel-bestanden
OpenOffice kan dat dus niet goed. Zij simuleren compatibility met een formaat dat grotendeels hetzelfde is maar dat betekent dat ze er ook wel eens naast zitten. Misschien maar in 1 op de 1000 of zelfs nog minder vaak voorkomende bestanden maar toch niet 100%.
In spreadsheet rekensheets toch een potentieel relevant issue

Waarom kan Excel niet als het Lotus leest of schrijft rekening houden met een bug, en als het Excel of ISO leest en schrijft daar geen rekening mee houden?

Omdat de lotus/excel binary bestanden geconverteerd moeten kunnen worden naar het nieuw Office Open XML formaat. Een conversie naar een ander datum formaat vereist dat de implementatie een vaste waarde herkent. Je hebt in de conversie dan namelijk een break voor en na de fictieve 1900 schrikkeldag
Je kunt in een document dus:
<value-type="date" value="55"/>
wel converteren als je weet dat het date1900 datum is naar een willkeurig ander datum formaat.
Maar bij een niet bekende datum:
<value-type="date" value=date_to_integer(C10)- date_to_inter(sysdate())+ 60/>
weet je geen vaste waarde. Dit kan per dag varieren of afhankelijk van ingelezen brondata.
Omdat je dan niet weet of je datum in de spreadsheet voor of na 29-2-1900 zit kun je niet zonder meer converteren naar een ander formaat zoals OpenOffice dat wel doet.
Een spreadsheet implementatie zoals excel kan runtime wel de datum goed representeren omdat op dat moment een waarde voor de datum bekend is. De implementatie kan echter niet 100% compatibel naar een ander formaat converteren dat geen date1900 datum ondersteunt omdat de datum value in zo'n geval niet een vaststaand iets is dat in het spreadsheet is opgeslagen.

  • -2 / 2

ArjenB op Donderdag 10 April 2008 11:38

image

MS wringt zich dus in allerlei bochten om een formaat te ondersteunen dat in het leven is geroepen voor Lotus 1-2-3 dat alleen in Taka-Tuka-land nog met enige regelmaat gebruikt wordt, maar ziet er geen been in om formaten die door oude MS-Office worden geproduceerd niet meer te ondersteunen? Dat is toch niet konsekwent :-S

Los daarvan, beweren dat een ander product niet deugt maakt je eigen product niet beter. En dan moeten we nog even aannemen dat je bewering klopt.

  • 2 / 2

baseline op Donderdag 10 April 2008 12:28

image

MS wringt zich dus in allerlei bochten om een formaat te ondersteunen dat in het leven is geroepen voor Lotus 1-2-3 dat alleen in Taka-Tuka-land nog met enige regelmaat gebruikt wordt

DE bug is geintroduceerd in Lotus 1-2-3. Micrsoft heeft in Excel gekozen om een compatibel datum formaat te gebruiken. Volgens mij zijn er behoorlijk wat excel spreadsheets sinds die tijd geproduceerd.
Je kunt overigens Micrsoft best verwijten dat ze het probleem eerder hadden kunnen verminderen door in het verleden nieuwe bestanden met het decimale datum vanaf 1904 formaat uit te rusten. Dat wordt ook door de Office voor Apple versies gebruikt.
Dat had de omvang van het huidige issue verminderd.
Echter we kunnen ook rustig stellen dat eigenlijk vrijwel niemand in de laatste twintig jaar geklaagd heeft dat spreadsheet datums op die manier opgeslagen en verwerkt werden omdat datums in 1900 niet zo populair zijn. En voor een spreadsheet implementatie is het natuurlijk heel simpel te implementeren.

, maar ziet er geen been in om formaten die door oude MS-Office worden geproduceerd niet meer te ondersteunen
Je bedoelt de oude formaten geproduceerd tot 1994 ?

  • -2 / 2

ArjenB op Donderdag 10 April 2008 12:41

image

Ja, de formaten die tot 1994 geproduceerd werden. Prehistorisch in IT-termen, maar dat is Lotus 1-2-3 ook. Als OOXML tot ISO-standaard verheven wordt hoop ik dat die schrikkeldag-toestand toch nog eens herzien wordt, want volgens mij hoort zoiets niet in een standaard. Ik gruw van de manier waarop de procedure tot nu toe gelopen is, maar als de standaard er toch komt heb ik liever dat er nog aan OOXML geschaafd wordt.

  • 2 / 2

baseline op Donderdag 10 April 2008 14:39

image

Volgens mij is tijdens het ISO standaardisatie proces afgesproken dat in OOXML voortaan sowieso altijd de ISO 8601 datums gebruikt worden in spreadsheet.
Daarnaast er een dateCompatibility eigenschap komt in een spreadsheet mbt de toepassing van decimale datum.
Als die aanstaan dan kunnen de compatibele decimale datum met base 1-1-1900 (met bug) en met base 1-1-1904 datums gebruikt worden zoals voorheen. Als die dateCompatibility eigenschap van een spreadhseet uit staat (default) dan zullen decimale datums altijd een volledige datumrange van jaar -9999 tot 9999 representeren volgens de gregoriaanse kalender.
De functies geassocieerd met dateCompatiblity worden een onderdeel van transitionele conformance en moge niet gebruikt worden voor strict conformance.

  • -2 / 2

toiletpaper op Donderdag 10 April 2008 19:24

image

Volgens mij is tijdens het ISO standaardisatie proces afgesproken dat in OOXML voortaan sowieso altijd de ISO 8601 datums gebruikt worden in spreadsheet.
Dat is een goede zaak, als spreadsheets decimale datums nodig hebben, dan moeten ze dat maar online converteren. Dan kan die kwalijke spec uit OOXML. Dat heb ik een jaar geleden al voorgesteld, en jij was er fel op tegen. Dus ik neem aan dat dit dan een tegenvaller voor jou is.

Helaas weten we niet of dat gebeurd is omdat, hoewel ISO eist dat het verslag van de BRM er binnen een maand moet zijn, er nu nog steeds niet is.
Het term "Volgens mij" geeft aan dat jij het ook niet weet.

  • 1 / 1

toiletpaper op Donderdag 10 April 2008 20:23

image

webwereld.nl/comments/47637
Deze discussie is hier al gevoerd, lees het maar terug, en zie verschillende onbekenden op het strijdtoneel. Mensen die goed zijn ingevoerd in de Webwereld-personages weten precies wie wie is, en als je het niet weet.
Alle argumenten die hier dreigen te komen, zijn daar al voorbij gekomen.

(een interessante is het verschil tussen precisie en precies, in deze discussie, zoek maar eens op het woord precisie, ook hier maakte het OOXML-ontwerp een denkfout)

Sterkte en plezier ermee.

Met een beetje mazzel heeft OOXML, wat betreft datums het hoofd gebogen voor redelijkheid, namelijk ISO datum-notaties

  • 1 / 1

baseline op Vrijdag 11 April 2008 08:02

image

Ik schrijf het niet goed op.
De ISO datums 'kunnen' voortaan altijd gebruikt worden. Maar decimale datums dus ook.
Spreadsheet zullen dat vaak toch decimale datums gebruiken want decimale datums zijn veel efficienter in spreadsheets waar vee lgerekend wordt met datums. En ISO heeft het ook het waardebereik van de decimale datums juist uitgebreid zodat ze nog ruimer toepasbaar worden (ook voor 1900/1904).

  • -2 / 2

toiletpaper op Vrijdag 11 April 2008 09:51

image

Maar decimale datums dus ook.
Decimale datums zijn geen datums maar nummers. Je kunt een datum/tijd best als nummer weergeven, en er mee rekenen als ieder ander nummer, en dan weer teruggaan naar een datum.

Alleen in Excel is daar een trucje nodig, omdat het jaar 1900 een dag te veel bevat. Dat is stom van Excel, maar goed, dat is hun probleem.

OpenOffice heft hier geen probleem mee, je kan alles wat je doet in Excel opslaan, en weer openen, en weer naar OF, en noem maar op, en steeds slaagt OpenOffice het wonder te volbrengen (waar MS blijkbaar niet in slaagt), namelijk rekening te houden emt een bug in Excel als het Excel schrijft, en anders gewoon niet.

  • 2 / 2

toiletpaper op Vrijdag 11 April 2008 09:58

image

Spreadsheet zullen dat vaak toch decimale datums gebruiken want decimale datums zijn veel efficienter in spreadsheets waar vee lgerekend wordt met datums.
Dit klopt niet altijd want nummers kunnen geen precisie bevatten. En nu krijgen we de discussie van een jaar geleden toen je ook niet eht vercshil tussen precies en precisie snapte, en nu nog steeds niet, want anders zou je inzien dat ISO datums juist uitermate goed geschikt zijn om mee te rekenen. Er zijn hele C en Java-libraries rondom ISO datums gebouwd (waarschijnlijk ook andere programmeeromgevingen), die bliksemsnel kunnen rekenen met ISO datums.

Oh ja, wat betekent precisie:

Stel je hebt een tijdsinterval in uren nauwkeurig gemeten, een wetenschapper wil dan niet in honderdste uren een afronding krijgen, want dat is niet wetenschappelijk. Want dan zou je een precisie suggereren die er niet was, en in feite liegen.

ISO datum/tijd notatie maakt het mogelijk precisie aan te geven, er is over nagedacht.

In alle grote projecten ind e zorg rekent met met ISO, HL7, CEN 13606, in alle grote standaarden in de handel rekent men met ISO datums, Edifact, etc.
Inde natuurkunde wil men precisie opgeven, maar daar zou een numerieke tijd-weergave interessant kunnen zijn. Want daar werkt men soms met floating-points en doubles, ook in tijd. Maar dan heb je weer niet een bug nodig in het jaar 1900, liever vermijden die bug.

Dus wat is jouw probleem.

  • 2 / 2

toiletpaper op Vrijdag 11 April 2008 10:02

image

Het hele verhaal van ISO-datums is hier al eens uitgelegd
webwereld.nl/co...8#comment_83170

  • 1 / 1

toiletpaper op Vrijdag 11 April 2008 10:07

image

Hier wordt eht woordje proecisie nog eens uitgelgd
webwereld.nl/co...#comment_262725

  • 1 / 1

baseline op Zondag 20 April 2008 19:54

image

ISO datum/tijd notatie maakt het mogelijk precisie aan te geven, er is over nagedacht

Wat een flauwekul. Decimale datums zijn een continue formaat waarmee je in principe elke datumtijd tot in het oneindige nauwkeurig kunt vastleggen.
Je wordt slecht beperkt door je implementatie.
Bij de ISO datumtijdens die in een string zijn opgelagen wordt onbeperkte nauwkeurigheid bereikt door (jawel!!) over te gaan op decimale tijden. Twaalf uur in ISO is "12:00" maar als je er 1 miljoenste minuut bij op telt dan is het bijvoorbeeld "12:00,000001". ISO datums zijn gewoon presentatiestrings die als het op echte nauwkeurigheid aangaat gewoon aangevuld worden met een decimale fractie.

Het is echt genant dat je nauwkeurigheid als een argument voor ISO datums tov decimale datums aangeeft omdat de echt absolute nauwkeurigheid van ISO datums wordt onleend aan de decimale datumnotatie.
De voordelen van ISO datums die mede zijn ontwikkeld voor presentatie zijn niet nauwkeurigheid maar de leesbaarheid door mensen en de ondersteuning van tijdzones.

  • -2 / 2

toiletpaper op Zondag 20 April 2008 22:59

image

Bij de ISO datumtijdens die in een string zijn opgelagen wordt onbeperkte nauwkeurigheid bereikt door (jawel!!) over te gaan op decimale tijden.
Precies, voor jouw informatie, na seconde is er geen kleinere tijdseenheid en wordt indien er precisering wordt gewenst, deze in decimalen aangegeven.

Het verschil is de mogelijkheid tot precisering aangeven, die de decimale notatie an sich niet kent, maar deze discussie is al honderd keer gevoerd.
Onder andere hier:
webwereld.nl/co...#comment_262725

  • 1 / 1

baseline op Maandag 21 April 2008 18:18

image

Tja, een dat was een discussie discussie waarbij je probeerde de suggestie te wekken dat in de wetenschap ISO 8601 gebruikt word voor precisie aanduiding van durations. Echter in wetenschap gebruik je natuurlijk volstrekt geen ISO durations maar een (decimale) waarde in SI eenheden.
Je zegt daar dus geen "01:01.09,003" maar 3669,003 seconden ook weer een decimale tijdsaanduiding.
In wetenschap is tijd namelijk een rekeneenheid en met ISO strings kun je niet rekenen maar met decimale waardes wel. IS eenheden werken met decimale eenheden en niet met 60-voud eenheden als minuten en/of uren.

  • -2 / 2

toiletpaper op Dinsdag 22 April 2008 00:01

image

Echter in wetenschap gebruik je natuurlijk volstrekt geen ISO durations maar een (decimale) waarde in SI eenheden. Je zegt daar dus geen "01:01.09,003" maar 3669,003 seconden ook weer een decimale tijdsaanduiding.
Je moet niet net doen alsof jij de heel wetenschappelijke wereld kent.
Want ik ken een wetenschappelijke wereld waarin wel ISO durations de voorkeur genieten boven decimale notaties, en om de simpele reden dat ISO durations de mogelijkheid hebben om precisie op te geven. Di mogelijkheid hebben decimale notaties niet.

Nog een keer:
01:01.09,003 geeft aan dat je in milliseconden nauwkeurig iets weergeeft, de werkelijke waarde kan best 01:01.09,003432 zijn, maar de notatie geeft aan dat dat niet gemeten is.
3669,003 geeft niet aan hoe nauwkeurig de tijdmeting is, is die in milliseconden, of in microseconden Dat is niet af te leiden, staat hier 3669,003 of 3669,003000? Of betekent dit dat er ook 3669,003432 kan staan? Zuiver getalsmatig kan dat er niet staan, zuiver getalsmatig kan dit geen afronding zijn op 3 cijfers, althans, dat is er niet aan te zien, dus ongewis.

In de wetenschappelijke hoek waar ik regelmatig kom wil men dit wel weten, vandaar dat men de voorkeur geeft aan ISO notatie, omdat de mogelijkheid staat precisie (=nauwkeurigheid) op te geven.

Net als vorige keer toen wij deze discussie voeren haal jij de woorden precisie en precies door elkaar. Of te wel, de woorden nauwkeurigheid en nauwkeurig.

De ISO notatie staat wel toe om precisie weg te laten, en dus hetzelfde te doen als de decimale notatie. Omgekerd kan het niet. Dus is de ISO notatie feature-rijker, en wordt daarom ook meer gebruikt.

Maar ik weet dat Brian Jones dit niet snapt en jij ook niet. Dat is goed te zien.

Het zij zo. Paarlen voor de ......

  • 1 / 1

baseline op Dinsdag 22 April 2008 10:59

image

In SI eenheden is prima aan te geven welke mate van precisie gebruikt wordt.
Veel beter nog dat in ISO 8601.

Je hebt in de SI eenheden namelijk een vastgelegd stelsel van SI-prefixes daarvoor.
Zo heb je juist ms of us om waardes milli- en microseconden aan te geven. Dat stelsel van SI-prefixes is natuurlijk veel uitgebreider dan de ISO 8601 notatie.
Je maakt jezelf met elke post belachelijker door ISO durations voor nauwkeurigheid te vergelijken met de officiele SI eenheid van tijd.

  • -2 / 2

toiletpaper op Dinsdag 22 April 2008 11:40

image

Veel beter nog dat in ISO 8601.
Je hebt in de SI eenheden namelijk een vastgelegd stelsel van SI-prefixes daarvoor.
SI is een andere oplossing, ISO 8601 heeft echter als voordeel ook dat het behalve durations ook tijdstippen kan aangeven, en een tijdzone notatie kan bevatten.

In elk geval wordt ISO notatie heel vaak gebruikt, ook in de wetenschappelijke wereld, ook in de handel (Edifact), ook in de medische wereld.

De belangrijkste reden hieroe is de goed doordachte eenduidigheid, en de beschikbaarheid van heel veel geoptimailiseerde libraries voor praktisch iedere programmeer-omgeving.

Samengevat:
Ik snap jouw oppositie tegen de ISO notatie niet. Het is compleet, het heeft tijdzone, precisie aanduiding, het is instaat precies te zijn tot iedere gewenste eenheid, het wordt wereldwijd volop gebruikt, en het heeft geoptimaliseerde libraries.

Je maakt jezelf met elke post belachelijker door ISO durations voor nauwkeurigheid te vergelijken met de officiele SI eenheid van tijd.
Ah, weer een krachtig voorbeeld van baseline's manieren om zichzelf porum te geven., was leuk, maar wordt afgezaagd.

  • 1 / 1

baseline op Dinsdag 22 April 2008 22:15

image

Ik heb niks tegen ISO datum maar wel tegen jou redenties waarom ISO datums beter zijn.
zoals ik al eerder zij zitten de voordelen van ISO datum in de lessbaarheid/interpretatiemogelijkheden van mensen en het gebruik van tijdzones.
Dan kom jij met nauwkeurig, precisie en gebruik in de wetenschap als argumenten.
Dat is gewoon triest.

En nu hier boven heb je toch eindelijk door dat tijdzones inderdaad een grootevoordeel is. ISO datum zijn geniaal voor communicatie tussen mensen en voor gebruik van exacte tijdstippen over de planeet. Inderdaad zal een handelsysteem daar dus heel goed gebruik van kunnen maken. Net als banken en eigenlijk alle andere plaatsen waar je exacte datumtijden wil registreren. Ook Office Open XML gebruikt dergelijke datums.

Waar de string ISO datums echter niet geschikt voor zijn is geautomtiseerd rekenen en vergelijken. Dat kan pas na goed na een (inlees) conversie naar een ander formaat. Dus ISO datum zijn vaak heel practisch maar zijn niet per definitie altijd beter dan andere datum tijd formaten. In spreadsheets is decimale tijd veel efficienter voor het rekenen en vergelijken en in bijvoorbeeld wetenschap is een tijds periode veel beter vastgelegd in SI eenheden voor berekeneningen.

Ik heb niets tegen ISO datums maar jij hebt een idee fixe dat ISO datum altijd het beste zijn en dat dat niet altijd voor alle doeleinden zo is wil je blijkbaar niet erkennen.

  • -2 / 2

toiletpaper op Dinsdag 22 April 2008 23:33

image

Waar de string ISO datums echter niet geschikt voor zijn is geautomtiseerd rekenen en vergelijken. Dat kan pas na goed na een (inlees) conversie naar een ander formaat
Als je ze wil bewerken, dan is het idnerdaad het beste om ze te converteren. Dan doen ook al die libraries intern, en op het moment dat ze weer naar buiten komen (in OOXML bewaren) dan maak je er weer een ISO datum van. Dan heb je een fileformaat dat conform internationale standaard leesbaar en eenduidig is, en veel gebruikt, en intern kun je snel rekenen met getallen. Databases werken ook met ISO datum notaties, juist vanwege de eenduidigheid. In Oracle is de ISO datum-notatie standaard in SQL. Ook MS SQL kan hier mee overweg. Kijk wat een rijkdom aan interoperabiliteti dit zou opleveren.

Dat is al jarenlang de dagelijkse praktijk.

We zijn nu weer terug bij de discussie van een jaar geleden, toen ik dat ook zei. En toen zeik, en n u zeg ik het weer, het is jammer dat OOXML geen ISO datum/tijd/duration-notatie afdwingt voor opslag.
Het is een gemiste kans

Het kost een microseconde om een decimale datum naar een ISO datum te converteren. In een spreadsheet met 1 miljoen datums zou het bewaren hierdoor 1 seconde langer duren. Dus dat kan geen argument zijn.
Dan kom jij met nauwkeurig, precisie en gebruik in de wetenschap als argumenten.
Dat is gewoon triest.
Leg eens uit, waarom is dat triest. je kan het met me oneens zijn, maar om het triest te noemen, vind ik niet bepaald positief in een discussie.

ISO 8601 in wetenschap?
Komt heel veel voor, juist vanwege de eenduidigheid, en de mogelijkheid om precisie aan te geven.
Als jij en tijdmeting in een seconde nauwkeurig doet, dan wil je niet dat een ander dit interpreteert als een tijdmeting gedaan in een milliseconde nauwkeurig. ISO voorziet hier in. Dat is een goede reden waarom het vaak wordt gebruikt. Wellicht voorzien andere standaarden hier ook in, maar naast de precisie aanduiding heeft ISO meer voordelen.

Laat ik het iemand anders laten zeggen:
www.cl.cam.ac.u...5/iso-time.html
Advantages of the ISO 8601 standard date notation compared to other commonly used variants

Ik laat het hierbij.

  • 1 / 1

toiletpaper op Zondag 20 April 2008 23:02

image

Het is echt genant
Zou je dit soort kwalificaties in de toekomst achterwege willen laten. Ikzelf kan er wel tegen, maar het lijkt mij onplezierig voor die ene lezer die zover is gekomen, en die toch wel zo slim moet worden geacht dat hij/zij zelf kan uitmaken wat er genant is.

  • 1 / 1

Bolleke op Dinsdag 22 April 2008 21:10

image zomerhack badge 3

Wat een flauwekul. Decimale datums zijn een continue formaat waarmee je in principe elke datumtijd tot in het oneindige nauwkeurig kunt vastleggen.
Sorry Baseline, maar dit is echt klinkklare onzin. Dit gaat nl. alleen op als je het allemaal eens bent over het nulpunt, en wat de eenheid is. Maar dan is er verder 0.0 (forgive the pun) verschil met ISO-datums, behalve dan dat de laatste VEEL makkelijker te lezen/parsen/verwerken zijn, en bovendien veel eenduidiger zijn.

Maar wat dit verder met het feit dat OOXML een dag teveel heeft te maken heeft ontgaat me ten enen male. Overigens, er is een reden dat wetenschappers en andere mensen die precisie en betrouwbaarheid verwachten van hun berekeningen niet met Excel werken.

  • 2 / 2

Bolleke op Donderdag 10 April 2008 21:14

image zomerhack badge 3

Ik zie werkelijk het probleem niet.

MS Office leest een oud binair Excel bestand in. MS Office corrigeert intern de schrikkeljaar-bug.

Save-as OOXML > De goede waarde wordt weggeschreven
Save-as oud-binair > De foute waarde wordt weggeschreven

Er is gewoon echt werkelijk waar geen enkele, maar dan ook geen enkele, zinnige reden te bedenken waarom dat in een ISO-standaard zou moeten zitten. It's your bug - deal with it.

Het heeft NIKS te maken met formules of startdata. Het is gewoon een rekenfout, en die hoort NIET in een standaard.

  • 3 / 3

toiletpaper op Donderdag 10 April 2008 22:03

image

dank voor deze heldere verwoording, ik kan het niet beter zeggen

  • 1 / 1

baseline op Vrijdag 11 April 2008 07:50

image

Save-as OOXML > De goede waarde wordt weggeschreven

Lees je uberhaupt wel.
Hoe kan je de goede waarde wegschrijven als er geen waarde in staat. Bij een conversie van dit datum issue moet je toch echt weten of de waarde in het decimale datumveld groter of kleiner dan 60 (29-2-1900) is.

Jij bent waarschijnlijk van de OpenOffice methode. We converteren naar een ander formaat ongeacht de inhoud. Dat leverty echter geen 100% compatibiliteit op.

Het tekent echt dat je dat soort simpele zaken niet ziet dat je niet begrijpt wat compatibliteit is of niet begrijpt wat spreadsheets eigenlijk zijn.

  • -2 / 2

toiletpaper op Vrijdag 11 April 2008 09:11

image

Lees jij uberhaupt wel
We converteren naar een ander formaat ongeacht de inhoud. Dat levert echter geen 100% compatibiliteit op.
De compatibiliteit zit in de uitkomst, als het mogelijk is om goed met datums te rekenen, dan is het doel bereikt. Als jij beweert dat Openoffice niet goed met datums rekent, is dat een ernstige beschuldiging, die je moet aantonen. Zeg maar wat ik moet doen om een fout te produceren, ik zal het gelijk proberen.

Ook vanuit een Excel bestand, zeg maar hoe een Excel bestand moet uitzien, en wat ik moet doen.... om in OpenOffcie/Excel/iedere mogelijke combinatie een fout te producren

Volgens mij kun je dat niet, en ben jij diegene die
- of een kromme redenatie probeert recht te praten
- of er zelf niks van snapt
(het resultaat zal het zelfde zijn)

  • 1 / 1

baseline op Vrijdag 11 April 2008 08:13

image

Als je echt denkt dat je een formule in het ene formaat zo makkelijk in een ander formaat kan wegsvhrijven doe dan maar eens een poging om deze fictieve formule uit een cell

<value-type="date1900" value="date_to_integer(C10) - date_to_integer(sysdate()) + 60" />

weg te schrijven als dit ODF datum formaat (je mag ook de base veranderen)

<value-type="date" base="1899-12-31" value=... >

De waarde na conversie moet dan natuurlijk correct zijn in alle mogeliijk scenario's
voor de formuleuitkomst.

  • -2 / 2

toiletpaper op Vrijdag 11 April 2008 09:16

image

Hier zit je verkeerd. ik ga geen ODF met de hand schrijven, ik ga ODF genereren, zeg hoe ik ODF moet genereren dat een fout produceert. Het is natuurlijk vrij makkelijk om handmatig een fout aan te brengen in ODF.
De waarde na conversie moet dan natuurlijk correct zijn in alle mogeliijk scenario's
voor de formuleuitkomst.
Je moet ook aangeven in welk scenario het fout gaat. Een bug aantonen doe je door te zeggen, bewijs maar dat het altijd goed is, een bug aantonen doe je door te zeggen waar het fout gaat.

En zolang jij geen reproduceerbare fout kunt benoemen weiger ik om te geloven dat het logischerwijze noodzakelijk is om het 1900 onterecht als schrikkeljaar te zien.

  • 1 / 1

toiletpaper op Vrijdag 11 April 2008 09:43

image

date_to_integer(C10) - date_to_integer(sysdate()) + 60
Ik heb deze formule, in iets gewijzigde vorm in ODF ingevoerd, want SYSDATE() eet hij niet, dat heet NOW().
Volgens mij is SYSDATE iets uit Oracle.

In elk geval

komt eruit:
09/01/1900 - 11/04/2008 + 60 = 26/11/1791
als ik de + 60 weg laat komt eruit:
09/01/1900 - 11/04/2008 + 60 = 27/09/1791

(volgens mij klopt deze uitkomst)

En de cel/formula onderwater ziet er als volgt uit:

<table:table-cell xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" table:formula="oooc:=10 - NOW() + 60" xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" office:value-type="date" xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" office:date-value="1791-11-26T14:20:09" xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" >
<text:p xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0">26-11-1791</text:p>
</table:table-cell>

Dus misschien kun je even beter aangeven wat je bedoelt, want volgens mij zit jij gewoon iemand anders te citeren die ook weer iemand anders citeert, ik ben benieuwd!!

  • 2 / 2

baseline op Vrijdag 11 April 2008 11:35

image

Het is interesant hoe jij een cell referentie "C10" vertaalt naar een datum. Ik bedoelde daarmee een onbekende afgeleide datumwaarde aan te geven.
Verder is het appart dat je de systeemdatum vertaal naar vandaag voor je converteert.
De systeemdatum is namelijk geen onderdeel van het bestand maar een runtime gegeven.

Als je de syteemdatum eerst vertaalt dan is het bestand inhoudelijk niet meer hetzelfde.
Dat is waarom een spreadsheet dat runtime wel kan weten. De spreadsheet kan dat kijken wat er in cell C10 zit (bijvoorbeeld een andere formule, een gelinkt spreadsheet of een DB query resultaat) en de spreadsheet kan runtime de systeemdatum vertalen naar de syteemdatum van die dag.
Daarom kan een implementatie zoals een spreadsheet de juiste datum op dat moment tonen. Dat kun je echter niet wegschrijven in het bestand omdat die informatie weliswaar runtime beschikbaar is maar geen onderdeel vormt van de info in het bestand.

Je kunt dus niet zomaar de formule converteren en eenduiding wegschrijven omdat je niet weet wat er in cell C10 staat als iemand anders het document op een ander moment in een andere omgeving opent en je weet ook niet wat dan de systeemdatum zal zijn. deze informatie zit niet in je bestand en kun je niet in je conversie betrekken.

Als je jouw methode gebruikt dan is er een verschillende resultaat mogelijk als je het document op twee verschillende dagen converteert.

  • -2 / 2

toiletpaper op Vrijdag 11 April 2008 11:47

image

Het is interesant hoe jij een cell referentie "C10" vertaalt naar een datum. Ik
Ah, ik dacht dat jij datum als numeriek gegeven 10 bedoelde, dat sysdate klopte al niet, dus had ik de rest ook geraden. maar wat wil je nou communiceren of katten?

Helaas heb ik vandaag geen tijd meer voor jou, morgen is een nieuwe dag

  • 1 / 1

toiletpaper op Vrijdag 11 April 2008 11:50

image

Je kunt dus niet zomaar de formule converteren en eenduiding wegschrijven omdat je niet weet wat er in cell C10 staat als iemand anders het document op een ander moment in een andere omgeving opent en je weet ook niet wat dan de systeemdatum zal zijn.
De functie sysdate() bestaat niet, volgens mij, dus wat probeer je nou te zeggen. De functie now() bestaat wel. En het is logisch dat die de tijd van nu weergeeft.

  • 1 / 1

toiletpaper op Vrijdag 11 April 2008 11:53

image

Als je jouw methode gebruikt dan is er een verschillende resultaat mogelijk als je het document op twee verschillende dagen converteert.
De functie now() wordt berekend op het moment van herberekening, ik neem aan dat dat gewenst is. Misschien moet je toch wat duidelijker worden, en ook even uitleggen wat dit met de datumbug uit Excel te maken heeft, want dat is het onderwerp, ook al probeer jij het stiekem te verschuiven. (waarschijnlijk omdat je daar vast zit, en iedere keer trap ik er op nieuw in, die afleidmethodes van jou)

  • 1 / 1

baseline op Vrijdag 11 April 2008 13:19

image

Het datum issue in Excel, een vroegere bug in Lotus 1-2-3, vereist dat je een decimale datum voor 29-2-1900 net iets anders bepaal als na 29-2-1900.
Als je deze datum wilt converteren naa een ander datumformaat moet je de datumts voor 29-2-1900 iets anders behandelen als de datums daarna. Dat kan dus alleen op het moment dat je de datum ook echt weet. In een spreadsheet kun je datums opslaan als een formule. In het bestand is dus vaak niet de echte datum aanwezig maar en formule die op runtime kan leiden tot een echte datum. Een spreadheet kan dus alleen op runtime zien of de decimale datumwaarde voor of na 29-2-1900 ligt en die datum correct tonen aan de gebruiker.
Het bestand bevat die informatie gewoon weg niet altijd.

Als je dus in het bestand de formule wilt converteren naar een ander formaat dat niet de 1900 datums bevat dan kun je dat niet met 100% zekerheid doen. Je kunt natuurlijk wel er vanuit gaan dat de methode voor decimale datums na 29-2-1900 altijd goed is. Dan heb je echte niet volledig compatibiliteit.

  • -2 / 2

ArjenB op Vrijdag 11 April 2008 13:26

image

Ik zie nog steeds niet de noodzaak om die kreupele Lotus-1-2-3-erfenis in een ISO-standaard mee te nemen.

  • 2 / 2

ArjenB op Vrijdag 11 April 2008 13:50

image

OpenOffice is in staat om te gaan met die Lotus 1-2-3 toestand, of dat perfect gaat interesseert me even niet. Dat OpenOffice bestanden produceert volgens ODF en bestanden die door Excel te lezen zijn betekent niet dat het Excel-formaat ook aan ODF moet worden toegevoegd. ODF en OOXML beschrijven bestandsformaten, geen applicaties. Op dezelfde manier is het ook niet noodzakelijk om die Lotus 1-2-3 toestand in OOXML te stoppen.

Wat heb ik gemist?

  • 2 / 2

baseline op Vrijdag 11 April 2008 14:39

image

Kijk dat je aangaaft dat je het je niet intereseert of het perfect gaat zegt alles.
Je accepteert conversie issues.
Dan is compatibilitiet voor jou geen issue of onbelangrijk.

OOXML heeft juist expliciet in de doelstelling van het formaat opgenomen dat compatibiliteit met bestaande Office documenten wel heel belangrijk is.

Dat tekent precies waarom OOXML op een antal punten ook gewoon heel andere doelen dient dan ODF.

  • -2 / 2

ArjenB op Vrijdag 11 April 2008 15:02

image

Je hebt me nog niet er van kunnen overtuigen dat geen applicatie in staat zou kunnen zijn om een Lotus-1-2-3-datum zodanig te hanteren dat er een ODF-conforme datum uit komt. De vertaling van Lotus 1-2-3 zie ik als een applicatieprobleem, geen probleem van bestandsstandaarden.

  • 3 / 3

ArjenB op Vrijdag 11 April 2008 15:16

image

Natuurlijk zie ik de voordelen van compatibiliteit, en als het even kan perfectie daarin. Maar dat is een zaak van de applicatie, en niet van de aanwezigheid van een door de applicatie te verwerken formaat in ODF of OOXML.

Dus: ook geen Excel/Lotus 1-2-3 formaat in ODF, alleen omdat een applicatie die ODF verwerkt ook dat andere formaat aan kan.

Het is mogelijk om een ISO-standaard te formuleren voor vierkante wielen. Het kan, maar het is de vraag of je daar iemand blij mee maakt.

  • 3 / 3

ArjenB op Vrijdag 11 April 2008 22:04

image

Kijk dat je aangaaft dat je het je niet intereseert of het perfect gaat zegt alles.
Je accepteert conversie issues.
Dan is compatibilitiet voor jou geen issue of onbelangrijk.

Ten overvloede: compatibiliteit is wel een issue voor me. Ik probeerde een ander punt te maken, los van de kwaliteit die OpenOffice bereikt heeft in de verwerking van Lotus 1-2-3 spul.

  • 2 / 2

toiletpaper op Vrijdag 11 April 2008 21:34

image

Als je dus in het bestand de formule wilt converteren naar een ander formaat dat niet de 1900 datums bevat dan kun je dat niet met 100% zekerheid doen. Je kunt natuurlijk wel er vanuit gaan dat de methode voor decimale datums na 29-2-1900 altijd goed is. Dan heb je echte niet volledig compatibiliteit.
Nogmaals, noem mij een handeling die ik in Excel moet verrichten, naar ODF moet converteren, end an weer terug naar Excel, en dat er dan iets anders uitkomt. Met andere woorden bewijs dat er situaties zijn die fout gaan bij conversie naar ODF en terug.

Dat vorige voorbeeld deed het gewoon goed, daarbij was het geen ODF dat je toonde, en rijp voor misverstanden, maar goed, ik ben eruit gekomen, en er is geen incompatibiliteit met Excel aangetoond, dus nu een simpele handeling in Excel die een conversie naar ODF en weer terug naar Excel niet overleeft.

Moet toch een makkie voor je zijn, waarschijnlijk hebben je vriendjes het al gedaan, en kun je volstaan met een link. Ik ben benieuwd.

  • 2 / 2

baseline op Zaterdag 12 April 2008 10:32

image

[quote]Dat vorige voorbeeld deed het gewoon goed, daarbij was het geen ODF dat je toonde, en rijp voor misverstanden, maar goed, ik ben eruit gekomen, en er is geen incompatibiliteit met Excel aangetoond [quote]

Nee dat is helemaal niet juist

Jij vertaalde de formule naar een andere met gebruikt van de actuele systeemdatum.
Als je de zelfde conversie nu nog een keer doet komt een ander resultaat uit. Dat is geen conversie. Je hebt de info veranderd door toepassing van runtime info alleen geldig op die dag.

Ik kan het niet beter uitleggen dan ik bovenstaand al meerdere keren heb gedaan.
Als je niet begrijpt dat je voor 100% conversie van date1900 datum moet weten voor elke situatie of deze onder of boven 29-2-1900 ligt en dat je dat in een spreadsheet document niet altijd kunt weten dan begrijp je gewoon onvoldoende van conversie en spreadsheets.

  • -2 / 2

baseline op Zaterdag 12 April 2008 11:29

image

Misschien was mijn voorbeeld te complex
Een versimpelde versie. In cell C10 zit een voor jou onbekende geldig tekstuele datumstring die wordt bepaalt door de tijd en omgeving waar de spreadsheet zich kan bevinden (bijvoorbeeld door een query uit een database).

De datum wordt 1 op 1 gerepresenteerd door onderstaande formule die de datum omzet naar een decimaal datumformaat
<value-type="date1900" value="date_to_integer(C10)"/>
In bovenstaande formule zit dus een onbekende decimale waarde in de range van 1-59, 61 en hoger.
Nu moet je bovenstaande formule omzetten naar een decimaal ODF datumformaat zodanig dat de bovenstaande formule een geldige integer waarde bevat die de tekstuele stringdatum in C10 goed 1 op 1 representeert of daar nou "28-2-1900" (=59) instaat of "1-3-1900" (=61).


Ik heb even een vergelijkbaar testje gedaan met uit delen samengestelde datum in een binair excel spreadheet en die ingelezen in Google docs.
Eerst even een referentie poging gedaan met een vaste datumwaarde in de spreadsheet
Maar Google converteert dan dus direct al datums voor 29-2-1900 verkeerd zelfs als de waarde nog bekend is en in de spreadsheet staat.
www.imageno.com...ibv58d2pic.html
Dat is is eigenlijk nog voor het testen met flexibele datum.
Het lijkt erop dat Google de beperkingen van ODF al in de interne werking van het programma heeft ingebouwd.

  • -2 / 2

toiletpaper op Donderdag 10 April 2008 19:26

image

Je begrijpt gewoon geen apenootje van spreadsheets formules.
Sterk argument, misschien moet je me nog een keer kleuter noemen, daar ehb ik al helemaal geen weerwoord meer op.
En nog een paar keer IBM zwartmaken.

  • 1 / 1

toiletpaper op Donderdag 10 April 2008 09:04

image

Het tekent dat je niet veel van spreadsheets begrijpt.
Kwalificeer je altijd iedereen zo die het neit emt jou eens is?
Geen wonder dat denkfouten in jouw hoofd nooit worden gecorrigeerd.

  • 2 / 2

baseline op Donderdag 10 April 2008 11:40

image

En dat van iemand die mij eerder in de discussie nog calimero, en mij in een cetegorie plaatse van klungelaars en idioten.
Je weet gewoon niks van spreadsheets converteren en je luide opinie over het datumformaat in spreadsheet is een beetje genant in dat kader. Dat je denkt dat je eventjes het genoemde datum 1900 formaat met het schikkeljaar issue in 1900 makkelijk kan omzetten omdat Office Office dat (schijnbaar) ook doet is eigenlijk gewoon triest.


  • -3 / 3

toiletpaper op Donderdag 10 April 2008 19:20

image

triest of niet, ik lees liever argumenten

  • 1 / 1

toiletpaper op Donderdag 10 April 2008 19:28

image

En dat van iemand die mij eerder in de discussie nog calimero, en mij in een cetegorie plaatse van klungelaars en idioten.
Dat was in de context van jouw Jip en Janneke compatibliteitsoplossingen, waar, nu je zelf zegt, OOXML de oplossing lijkt te volgend ie ik een jaar geleden al suggereerde (ISO datumnotatie), en niet ik alleen, maar bijna iedereen behalve het kliekje van Brian Jones

  • 1 / 1

baseline op Vrijdag 11 April 2008 12:10

image

Jij noemt het Jip en Janneke oplossing omdat het begrip van 100% compatibiliteit aan jou niet besteed is.
Het is echter wel een groot belang in het werkelijke leven.
Dat je het idee hebt dat OpenOffice voldoende compatible is met de binaire MS Office bestanden zegt genoeg.
De compatibiliteit op dat niveau is namelijk gewoon niet voldoende. als je revisie informatie of graphische objecten in je document hebt zitten is de compatibliteit al vaak een stuk minder.
Wat bijvoorbeeld ik wel eens heb geconstateerd is dat bij inlezen in OOo van verstuurde brieven (wij hebben er miljoenen gearchiveerd in MS Office formaat) de onderste tekstregel van de pagina afviel zodat bij herafdrukken en opnieuw versturen de brief een tekstregel minder zou hebben. Dat was waarschijnlijk geen issue gerelateerd aan het formaat maar geeft wel aan dat gebrek aan compatibliteit in de kleinste kleine zaken al heel snel tot issue kan leiden.

  • -2 / 2

Bolleke op Vrijdag 11 April 2008 20:02

image zomerhack badge 3

Jij noemt het Jip en Janneke oplossing omdat het begrip van 100% compatibiliteit aan jou niet besteed is.
Er, misschien moet ik je het begrip "compatibiliteit" even uitleggen:

Compatibiliteit betekent /niet/ dat alles wat in formaat A zit 1-op-1 in formaat B moet worden overgenomen (ik zou dat liever "debiliteit" noemen).

Compatibiliteit betekent /wel/ dat je alles wat je met formaat A kunt, ook met B moet kunnen.

Dat is een subtiel maar zeer essentieel verschil in benadering. Is het mogelijk om in ODF, net als in Excel, in een veld een datum op te slaan, zodanig dat deze ook het type "datum" heeft (met alle gevolgen voor berekeningen van dien)?
Jazeker, dat is uiteraard mogelijk. Dus is er 100% compatibiliteit.

Nu is het bekend dat de applicatie waarop formaat A is gebaseerd een fout bevat, waardoor datums van voor 1 maart 1900 een dag verkeerd lopen. Wat moet formaat B doen?
Antwoord: helemaal niks. Het is aan implementerende applicaties om hier wel of niet rekening mee te houden. Zolang het document in formaat A blijft is er niks aan de hand; de applicatie weet dat hij daar rekening mee moet houden (of niet, maar die keuze is aan de applicatie). Sla je het op in formaat B dan sta je voor een keuze: sla ik de correcte datum op, of herbereken ik alle datums van voor die dag in 1900? De laatste oplossing ligt het meest voor de hand, maar omdat het theoretisch mogelijk is dat iemand per se de harde datums uit formaat A wil houden zou je de eerste ook aan kunnen bieden.

DIT IS ECHTER EEN ZAAK VAN DE APPLICATIE en heeft niks met compatibiliteit te maken. Ik snap werkelijk niet hoe je dit met droge ogen kunt beweren.

  • 3 / 3

baseline op Vrijdag 11 April 2008 21:04

image

B8ij een bestandformaat betekent compatibiliteit dat alles wat je in het ene formaat opslaat ook in het andere formaat kan worden opgeslagen.

Compatibiliteit betekent /wel/ dat je alles wat je met formaat A kunt, ook met B moet kunnen

  • -2 / 2

baseline op Vrijdag 11 April 2008 21:08

image

grrrrr, mislukte comment alert boven

  • -2 / 2

baseline op Vrijdag 11 April 2008 21:06

image

Compatibiliteit betekent /niet/ dat alles wat in formaat A zit 1-op-1 in formaat B moet worden overgenomen
Bij een bestandformaat betekent compatibiliteit dat alles wat je in het eerdere formaat kan opslaan ook in het andere formaat kan worden opgeslagen.

Alleen dan is namelijk conversie mogelijk van het oude naar het nieuwe formaat.

  • -2 / 2

Bolleke op Vrijdag 11 April 2008 21:20

image zomerhack badge 3

Bij een bestandformaat betekent compatibiliteit dat alles wat je in het eerdere formaat kan opslaan ook in het andere formaat kan worden opgeslagen.

Alleen dan is namelijk conversie mogelijk van het oude naar het nieuwe formaat.
Tja, je bevestigt zelf al mijn woorden: Uiteraard /kan/ je de datum opslaan, en er komt een /conversie/ bij kijken.

I rest my case.

Hetgeen wij kennelijk van mening over verschillen is of "alles" ook bugs behelst. Ik vind van niet, want bugs zitten in applicaties, niet in formaten. Maar goed.

  • 3 / 3

baseline op Zaterdag 12 April 2008 10:16

image

Je ziet het verkeerd als je aangeeft dat de bug in de applicatie zit.
Het zit namelijk opgeslagen in het datumformaat gebruikt in het bestandsformaat.
Er wordt namelijk een datum/tijd opgeslagen in een decimaal formaat maar met een gat erin.

Er is gewoon geen 100% betrouwbare manier om de informatie in het spreadsheet bestand opgeslagen te converteren naar een ander formaat zonder een dergelijk datumformaat. Office Open XML bevat wel een mogelijkheid tot 100% betrouwbare conversie van het datum formaat en biedt daarom wel compatibiliteit.

  • -2 / 2

toiletpaper op Zaterdag 12 April 2008 12:19

image

In OpenOffice type ik links de volgende getallen, en rechts laat ik die getallen als datum weergeven

1 31-12-1899
2 01-01-1900
3 02-01-1900
4 03-01-1900
5 04-01-1900
6 05-01-1900
.....
59 27-02-1900
60 28-02-1900
61 01-03-1900
Vervolgens bewaar ik deze als Excel 97, en ga op een Windows computer dit openen

1 01-01-1900
2 02-01-1900
3 03-01-1900
4 04-01-1900
5 05-01-1900
6 06-01-1900
.....
59 28-02-1900
60 29-02-1900
61 01-03-1900

En zie Excel, plakt er een niet bestaande datum tussen, en heeft een ander begin punt.
Het is dus niet zo dat Excel deze bug repareert in de weergave, het plakt er een niet bestaande datum in.
Dat vind ik nogal slordig van een spreadssheet, dat ie niet bestaande datums kan opnemen. over nauwkeurigheid gesproken.

Echter, het betreft hier een interne conversie van een integer naar een datum, want onder water heeft Excel natuurlijk alleen de integers bewaard.

Want als ik het bijbehorende ODF bestand in de XML's bekijkt, dan zien we dat ODF naast de geconverteerde nummerieke waarde ook de ISO datum bewaart, en de tekst weergave van de datum bewaart, en dus een foute interpretatie niet nodig hoeft te zijn.

Dus alles wat nodig is om tot een foutloze interpretatie van deze spreadsheet te komen is aanwezig. Ook Excel zou ODF foutloos kunnen interpreteren, en dan intern desnoods naar hoeveelheden gebakken apenootjes kunnen converteren.

<table:table-cell xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" table:formula="oooc:=[.A1]" xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" office:value-type="date" xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" office:date-value="1899-12-31" xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" >
<text:p xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0">31-12-1899</text:p>
</table:table-cell>


<table:table-cell xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" table:formula="oooc:=[.A2]" xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" office:value-type="date" xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" office:date-value="1900-01-01" xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" >
<text:p xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0">01-01-1900</text:p>
</table:table-cell>


Voor mij is de case closed, en heeft ISO ODF duidelijk de voorkeur, want het biedt volledige, niet fout interpreteerbare informatie. Zoals je verwacht van een ISO standaard.

  • 1 / 1

baseline op Zaterdag 12 April 2008 12:36

image

Ook Excel zou ODF foutloos kunnen interpreteren,
Natuurlijk kan Excel dat. Het is ook geen applicatie issue.
Office Open XML bevat ten slotte ook ISO datums waar MS Office gewoon prima mee om kan gaan.

Wat echter niet kan is alle date1900 datums uit de bestaande miljarden MS Office files op 100% eenduidige wijze converteren in ODF files.
Sterker nog, een bekende ODF gebaseerde applicatie kan deze helemaal niet eens correct inlezen als ze een date1900 datum bevatten:
www.imageno.com...ibv58d2pic.html

Je kunt de alle date1900 datums uit deze files echter wel 1 op 1 naar de open standaard Office Open XML files converteren.

Office Open XML biedt wel de compatibiliteit met de bestaande miljarden Office files zodat je de oude files zonder informatieverlies kan converteren naar Office Open XML en Opendocument biedt die mate van compatibiliteit gewoon niet.

  • -2 / 2

toiletpaper op Zaterdag 12 April 2008 13:20

image

Sterker nog, een bekende ODF gebaseerde applicatie kan deze helemaal niet eens correct inlezen als ze een date1900 datum bevatten:
Maar deze discussie gaat helemaal niet over applicaties maar over ISO formaten, en dan blijft mijn stelling dat ODF een eenduidige en foutloze interpretatie van data en datums bevat.

Eigenlijk samengevat wat jij probeert te doen is de standaard verwarren met de implementaties. De standaard af te keuren omdat applicaties fouten maken met conversies. Een doodzonde in standaarderingsland.

Dat er applicaties fouten maken, dat is vervelend, maar dat is geen argument bij het ontwerp van een ISO standaard. Ik blijf erbij dat het goed mogelijk is van buggy Excel naar goed ODF te converteren en omgekeerd, van goed ODF naar buggy Excel. Ik zie nog steeds geen reden waarom dit niet mogelijk zou zijn.

Dat concurrende office pakketten weigeren om een Excel-bug te implementeren is jammer, maar dat ligt niet aan de standaard, maar aan die applicatie, en aan MS dat al jarenlang toestaat dat Excel een bug heeft, en ook deze gelegenheid niet aangrijpt om die bug te repareren, ligt ook niet aan het ISO maar aan MS.

Het is gewoon uitermate slordig om een applicatiebug in een ISO standaard op te nemen, die bedoeld is om tientallen jaren later documenten te laten lezen. Dan heeft ODF wat dit issue betreft, duidelijk betere papieren.

En nu hou ik erover op, want ik kan me niet voorstellen dat er nog iets gezegd gaat worden wat niet al eerder is gezegd.

  • 1 / 1

baseline op Zaterdag 12 April 2008 15:19

image

Ik blijf erbij dat het goed mogelijk is van buggy Excel naar goed ODF te converteren en omgekeerd, van goed ODF naar buggy Excel. Ik zie nog steeds geen reden waarom dit niet mogelijk zou zijn.

Je houdt gewoon vol tegen beter weten in.
Ja daar valt niet tegenaan te redeneren.
Het is nou eenmaal niet in alle gevallen mogelijk om bestaande Office documenten 100% betrouwbaar te converteren naar ODF files.

En dat is niet alleen met dit datum issue maar het is een veelheid aan issues.

Wil je dus compatibiliteit met je bestaande Office binary files dan biedt Office Open XML dat wel en ODF dat niet!

  • -2 / 2

toiletpaper op Zaterdag 12 April 2008 15:48

image

het is een kwestie van keuze, converteren kan waarschijnlijk niet zonder gebruikerinteractie, omdat er geen mogelijkheid is waaraan een computer kan zien of er een (gewoon) nummer is bedoeld, of een datum.
(want als ie het wel kan zien kan ie eht ook converteren)

Dit probleem blijft altijd bestaan, iedere keer wanneer je een dergelijke situatie tegenkomt, ook wanneer de fout in een OOXML zit (Wat dus mogelijk is) en je wil dit OOXML door een andere dan Excel applicatie willen laten gebruiken (interoperabiliteit heet dat, daar dient alles toe), zal die applicatie aan een integer niet kunnen zien of het een datum betreft of niet.

Want als die applicatie het wel kan zien, kan die het ook converteren.

het is gewoon uitstel van executie wat er met OOXML gebeurt, voor je uitschuiven van eht probleem totdat de vraag toch actueel wordt in de verre toekomst, en dan weet helemaal niemand het meer.

  • 1 / 1

toiletpaper op Zaterdag 12 April 2008 13:30

image

Wat echter niet kan is alle date1900 datums uit de bestaande miljarden MS Office files op 100% eenduidige wijze converteren in ODF files.
Stel je bent op numerieke wijze met datums aan het rekenen, en voor dat doel heb je een serie datums naar ntegers geconverteerd, en dan vraag je Excel hoeveel dagen er tussen twee dfatums zitten. Bijvoorbeeld, 1 maart 1900 en 28 februari 1900.
Dan komt Excel met 2 terug.

Lekker hoor!

Een OOXML gebaseerde applicatie doet dat ook.

Lekker hoor!

Nou moeten wij ons allemaal ons goed achter de oren krabben, wat er hier normaal en wenselijk is.

Tot in de eeuwigheid der dagen doorgaan met deze belachelijke onzin? Zelfs opnemen in een ISO standaard?

  • 2 / 2

baseline op Zaterdag 12 April 2008 15:11

image

Tot in de eeuwigheid der dagen doorgaan met deze belachelijke onzin? Zelfs opnemen in een ISO standaard?

Aangezien het date 1900 formaat in de ISO standaard een transitional formaat is om compatibiliteit met oude documenten te garanderen zou je het niet moeten gebruiken in nieuwe files. Maar je kunt het wel gebruiken voor het converterwen van bestande files en dat kun je met ODF gewoon niet.

En natuurlijk bevat Office Open XML voor nieuwe files ook een normaal decimaal datumformaat en gebruikt het ook de ISO datumformaten.
Dus er is geen enkel probleem om nieuwe Office Open XML bestanden zonder meer correct aan te maken zonder zaken uit het verleden te continueren.

  • -2 / 2

toiletpaper op Zaterdag 12 April 2008 15:43

image

nou dat is een geruststelling, dan, hopelijk stopt Excel dan ook met het gebruiken van die bug.

  • 2 / 2

baseline op Zaterdag 12 April 2008 19:36

image

Dat lijkt me wel gewenst ja.
Het Office Open XML formaat is ook tijdens de ISO standaardisatie op een aantal punten verbetert en nu moet Microsoft dus ook deze verbeteringen gaan doorvoeren.
Hopelijk nog in de loop van dit jaar.

  • 0 / 4

Bolleke op Zaterdag 12 April 2008 19:43

image zomerhack badge 3

Wat echter niet kan is alle date1900 datums uit de bestaande miljarden MS Office files op 100% eenduidige wijze converteren in ODF files.
Ik probeer het je nog 1x uit te leggen, ditmaal met behulp van pseudo-code:

if (typeof(cell) == 'date') {
if (tyepof(file) == 'Excel binary') {
cell += cell < '1900-03-01' ? 1 : 0;
}
}

Het enige wat dus /niet/ kan is bepalen of je een datum moet verschuiven naar de "echte" dag, of de foutieve datum laten staan. Maar dat kan sowieso niet, je wilt die keuze juist maken want je wilt van die fout in je data af.

Tenminste, ik zou daar zelf dan toch wel graag vanaf willen. Een conversie naar een nieuw formaat is daar de uitgelezen gelegenheid voor. Bekende bugs dan toch behouden is werkelijk van de zotte.

  • 3 / 3

baseline op Zondag 13 April 2008 10:06

image

Die pseudocode werkt alleen als je dus kunt bepalen of de datum kleiner is dan 1-3-1900.
Dat is lastig als er in een cell alleen een formule of verwijzing staat en de datum dus niet een vast gegeven is.

Je pseudocode werkt alleen al je weet wat de waarde datum in 'cell' is. Iets wat je op runtime kan bepalen en waar een spreadsheet applicatie in principe prima mee om kan gaan maar iets wat niet per se is vastgelegd in het bestand.


  • -2 / 2

Bolleke op Zondag 13 April 2008 12:55

image zomerhack badge 3

Je pseudocode werkt alleen al je weet wat de waarde datum in 'cell' is. Iets wat je op runtime kan bepalen en waar een spreadsheet applicatie in principe prima mee om kan gaan maar iets wat niet per se is vastgelegd in het bestand.
Nee, uiteraard. Maar dat was dus ook de hele bedoeling niet. Op het moment dat de applicatie iets met een datumveld moet doen - en of die waarde daar hard instaat of uit een functie komt maakt dan niet uit - /en/ het is een oud Excel-bestand dan kan-ie die correctie daar intern overheen gooien. Liefst wel met een dikke vette waarschuwing dat de applicatie van waaruit geimporteerd wordt (Excel in dit geval) een datumbug bevat en dat je even goed moet nadenken en aangeven wat-ie ermee moet.

Zo bezien is de oplossing van OOXML eigenlijk nog veel slechter: de gemiddelde gebruiker kan op geen enkele manier snel zien of er nou de goeie datums worden gebruikt of niet. Het klinkt mij echt als een recipe for disaster in de oren, je weet eigenlijk al van tevoren dat dit fouten gaat opleveren...

  • 3 / 3

Bolleke op Zaterdag 12 April 2008 19:50

image zomerhack badge 3

Sterker nog, een bekende ODF gebaseerde applicatie kan deze helemaal niet eens correct inlezen als ze een date1900 datum bevatten:
Wat heeft het feit dat GoogleDocs standaard ODF gebruikt te maken met het feit dat-ie niet "goed" met Excel-bestanden omgaat? Sowieso lijkt het er eerder op alsof je GoogleDocs doc een andere offset gebruikt. Je Excel-voorbeeld toont het aantal dagen sinds 31-12-1899. GoogleDocs gooit daar nog een datum bovenop. Als je een dag van na 28-02-1900 had gebruikt had ik eerder de omgekeerde discrepantie verwacht: Excel die de schrikkeldag meetelt.

Kortom, ik snap a) je voorbeeld niet en b) je punt niet...

  • 2 / 2

baseline op Zondag 13 April 2008 09:37

image

Je telt verkeert.
Als je goed had geteld dan had je gezien dat het excel voorbeeld het date1900 met het schrikkeljaar issues gebruikt als basis en google docs dat formaat representeerd als een decimaal dateformat met basis 31-12-1899. Google telt er dus voor 29-2-1900 een extra dagje bij. Zodra de datum voorbij 29-2-1900 gaat dan komen deze datumformaten overeen en doet Google docs het wel weer zoals het in het binaire bestand is opgeslagen. Precies het conversieprobleem.

  • -2 / 2

Bolleke op Zondag 13 April 2008 09:50

image zomerhack badge 3

Zodra de datum voorbij 29-2-1900 gaat dan komen deze datumformaten overeen en doet Google docs het wel weer zoals het in het binaire bestand is opgeslagen. Precies het conversieprobleem.
Ah, zo bedoel je het. Nu snap ik je test beter.

Maar kennelijk kiest GoogleDocs er dus voor om dat zo op te lossen. Het blijft een naar verhaal, want je zit in Excel gewoon met een niet-bestaande dag en andere applicaties moeten daar iets mee. Een alternatieve oplossing zou zijn zoals in mijn pseudo-code voorbeeld van eerder, maar ik kan me voorstellen dat implementaties daar niet om staan te springen. Je code wordt er nl. niet schoner van. De echte oplossing zou zijn tijdens een conversie van een bestand waar data van zowel voor als na "de dag" in voorkomen handmatig aan te geven wat er mee moet gebeuren. Het is in elk geval iets dat je opgelost wilt zien als dit in jouw data voorkomt, ik kan me niet voorstellen dat er veel mensen zijn die blij worden van de gedachte dat hun documenten een niet-bestaande dag bevatten. Die willen dat eruit hebben.

  • 3 / 3

baseline op Zondag 13 April 2008 16:51

image

want je zit in Excel gewoon met een niet-bestaande dag en andere applicaties moeten daar iets mee

Excel (en andere spreadsheets die compatibel zijn met dit datum issue uit lotus 1-2-3) slaan die dag gewoon over. Dat is namelijk relatief simpel
Google docs lijkt een soort conversie vooraf door te voeren naar een intern decimaal formaat zoals ODF dat gebruikt en is dan niet meer compatibel

  • -2 / 2

toiletpaper op Zondag 13 April 2008 17:30

image

Excel (en andere spreadsheets die compatibel zijn met dit datum issue uit lotus 1-2-3) slaan die dag gewoon over. Dat is namelijk relatief simpel
Niet als je rekent met integers juist op die dag uitkomt of ervoor.
Bijvoorbeeld, als je aan excel vraagt van dag 61 een af te trekken, dan kom je op dag 60 uit, en als je dat als datum laat weergeven, geeft Excel zonder blikken of blozen 29/2/1900 aan (een niet bestaande dag dus.)

  • 1 / 1

baseline op Woensdag 16 April 2008 17:04

image

ik kan me niet voorstellen dat er veel mensen zijn die blij worden van de gedachte dat hun documenten een niet-bestaande dag bevatten. Die willen dat eruit hebben.

In 20 jaar is het nauwelijks iemand opgevallen dat dit zo is. Spreadsheet kunnen daar heel makkelijk mee omgaan.
Pas tijdens de standaardisatie van OOXML was het nota bene een medewerker van IBM Lotus divisie (dus eigenlijk bij de bron van dit issue) die daar een blogpost aan gewijd heeft en daardoor de ophef gecreerd heeft.

  • -2 / 2

ArjenB op Woensdag 16 April 2008 17:11

image

Over 20 jaar zullen mensen zich afvragen hoe 29 februari 1900 in vredesnaam in een ISO-standaard is gekomen. Ik hoop dat ik dan nog leef, maar ik denk niet dat ik dan in staat zal zijn om het uit te leggen. Dat kan ik nu namelijk ook niet.

  • 2 / 2

toiletpaper op Woensdag 16 April 2008 22:11

image

Pas tijdens de standaardisatie van OOXML was het nota bene een medewerker van IBM Lotus divisie (dus eigenlijk bij de bron van dit issue) die daar een blogpost aan gewijd heeft en daardoor de ophef gecreerd heeft.
Ah, jij denkt dat ze bij ISO zo dom zijn dat het niet was opgevallen dat er een applicatie bug in een platform onafhankelijke standaard zou worden opgenomen?
Het is dus weer de schuld van IBM.

Tja......

Niet NS is fout, ook niet hun fans, maar de rest van de wereld, duidelijk.....

Ik kan de gedachtengang vanuit deze beperkte visie uitstekend volgen

  • 0 / 2

toiletpaper op Maandag 14 April 2008 10:51

image

Microsoft heeft zich met de ontwikkeling en standaardisatie van Open XML uitgesproken vóór interoperabiliteit, vóór open standaarden en vóór keuze, stelt Hans Bos.
Wat je steeds vaker ziet bij OOXML-adepten is dat ze spreken van "Open XML". Toch is dat niet ISO gecertificeerd, maar er is sprake van een gore marketing truc.
Door de naam te wijzigen van "Office Open XML" naar "Open XML" wordt de naam semantisch losgekoppeld van "Office".

Ik weet dat dit onvermijdelijk is, baseline heft het al een paar keer in Wikipedia geprobeerd te wijzigen. Het is niet zomaar een argeloze verspreking, ook Hans Bos doet het in zijn artikel enkele keren, het is een langzaam verschuiven dan de coulissen om Office Open XML, (OOXML) los te koppelen van zijn historie en semantisch een generieke status te geven die het inhoudelijk neit verdient.

Want inhoudelijk is OOXML (dat ontkent ook niemand) bijna volledig gebaseerd op MS Office, en eerlijker zou zijn als ze de naam OOXML zouden wijzigen naar MSOOXML.

Dus, alweer, de vos Ballmer heeft dan wel zijn haren verloren, al die andere vosjes, zoals Hans Bos en baseline hebben zijn streken overgenomen.

In elk geval, zolang dit soort marketingtrucs doorgaan, en Microsoft in een soort van newspeak, hoop ik dat er volop oppositie wordt geboden in de vorm van MS-OOXML

  • 1 / 1

baseline op Woensdag 16 April 2008 16:44

image

baseline heft het al een paar keer in Wikipedia geprobeerd te wijzigen

Wil je niet onzin uitslaan. Of om in jouw taalgebruik te spreken, wil je ophouden met je gore leugens.

Als ik al in wikipedia de naam van het Office Open XML formaat aanpas dan pas ik alleen juist heel vaak de afkorting OOXML aan naar Office Open XML inclusief dus Office. Het is namelijk netter op een encyclopedische cite de volledige naam te gebruiken ipv de afkorting tenzij de afkorting meer betekenisvol is geworden dan de volledige naam. Bijvoorbeeld bij bestandsformaten waarvan de bestandsextentie overeenkomt met de afkorting.

Verder heeft deze naamgeving niks te maken met ISO standaardisatie want de officiele ISO/IEC naamgeving is veel langer. De officiele ISO naam voor ISO 29500 is zover ik weet
ISO/IEC 29500
Information technology -- Office Open XML file formats
en de naam voor ODF is
ISO/IEC 26300:2006
Information technology -- Open Document Format for Office Applications (OpenDocument) v1.0

Je suggestie MS-OOXML zou een lachwekkende naamgeving zijn aangezien de copyright rechten van Office Open XML liggen bij Ecma en ISO en niet bij Microsoft.
De officiele naamgeving naamgeving is dus enkele afhankelijk van hoe Ecma en ISO het formaat willen noemen.

Dat Microsoft medewerkers dat OpenXML noemen of dat tegenstanders het formaat graag oh-oh-xml willen noemen heeft verder nul en generlei betekenis.

De naam van het wikipedia artikel is gewoon Office Open XML wat bij beide standaardsorganisaties een gemeenschappelijk onderdeel is van de door hen gebruikte officiele naam. Dat lijkt me daarom heel correct gekozen.

  • -2 / 2

toiletpaper op Woensdag 16 April 2008 17:08

image

Dat Microsoft medewerkers dat OpenXML noemen of dat tegenstanders het formaat graag oh-oh-xml willen noemen heeft verder nul en generlei betekenis.
Niets gebeurt zonder reden, marketingtechnisch vind MS de naam OpenXMl beter dan Office Open XML
De naam van het wikipedia artikel is gewoon Office Open XML wat bij beide standaardsorganisaties een gemeenschappelijk onderdeel is van de door hen gebruikte officiele naam. Dat lijkt me daarom heel correct gekozen.
Jij hebt verschillende keren in Wikipedia geprobeerd de term OpenXML binnen gesmokkeld te krijgen, niet als titel van het lemma, maar als alternatieve naam aangeboden in het lemma, het is een paar keer geweigerd, wat nu de status is weet ik niet.

Het feit dat jij dat geprobeerd ehbt, dat Hans Bos beide namen door elkaar gebruikt, en dat ookd e webwereld redactie de naam OpenXML begrint te gebruiken zijn duidelijk signalen dat men graag de naam verschoven wil hebben van "Office Open XML" naar OpenXML, en indien dat het streven is van MS om dat gedaan te krijgen, nogmaals, alles wijst er op, dan ben ik er voorstander van dat in het kader van ludieke tegenactie de naam inderdaad wordt veranderd, maar dan naar, zoals ik voorstelde MS-OOXML, want uiteindelijk is dat toch waar het op neer komt.

  • 1 / 1

toiletpaper op Woensdag 16 April 2008 22:16

image

Sterker nog, als de standaard OpenXML had geheten in plaats van OfficeOpenXML, dan was het nooit een standaard geworden. Zoveel onverholen arrogantie wordt zelfs bij ISO niet geaccepteerd. Dus is de standaard als OfficeOpenXML door ISO gefietst, en gaat nu in de volksmond, opgelegd door MS marketing OpenXML genoemd worden. Een duidelijk en klassiek voorbeeld van Newspeak.

  • 2 / 2

baseline op Donderdag 17 April 2008 08:02

image

Jij hebt verschillende keren in Wikipedia geprobeerd de term OpenXML binnen gesmokkeld te krijgen
Dat is gewoon ronduit een leugen.
Dat heb ik helemaal niet gedaan. Ik heb juist altijd voor de naam Office Open XML gestaan.
Je blijft maar alles bij elkaar liegen.

  • -2 / 2

baseline op Donderdag 17 April 2008 08:19

image

Ik heb het nog even nagekeken maar in januari 2007 na de standaardisatie door Ecma was er discussie over de namen Ecma Office Open XML en Microsoft Office Open XML en was ik zelfs degene die een voorstel heb gedaan om het formaat Office Open XML te noemen op de wikipedia pagina's.

Het is echt heel triest hoe jij probeert leugens te verspreiden en personen persoonlijk aan probeert te vallen.
Zielig mannetje

  • -2 / 2

toiletpaper op Donderdag 17 April 2008 09:50

image

Wat staat er nu als eerste regel in het artikel, waar jij je in honderden edits mee hebt bemoeit?
Office Open XML (ISO/IEC 29500 also referred to as OOXML or OpenXML)
Op 26 maart verwijderd door Partyoffive

En weer teruggezet door, niemand minder dan Alex Brown, de druk bezette ISO voorzitter vond nog een gaatje in zijn agenda om Wikipedia aan te passen.

Over een gepreoccupeerd ISO voorzitter te spreken.

Afgelopen september was hij nog van mening dat de term OpenXML fout was en diende te worden vervangen door OOXML, kun je zien hoe de coulissen verschuiven

Maar Albert, je hebt gelijk, ik moet me verexcuseren, ik had me vergist, maar wat ik door deze vergissing heb aangetroffen is toch ook wel weer een juweeltje van waarheidsvinding.
Jij hebt nooit de term OpenXML toegevoegd, dat heeft Alex Brown gedaan, jij hebt het wel goed gevonden dat hij dat deed.
Persoonlijk vind ik het nogal gestoord dat een voorzitter van een ISO werkgroep, die toch boven de partijen moet staan zich bezig houdt met wikipedia-edits

Oh, oh, wat een doorgestoken kaart, de voorzitter van de ISO werkgroep heeft honderden Wikipedia-edits aangebracht.

  • 2 / 2

toiletpaper op Donderdag 17 April 2008 08:22

image

Ik zal morgen de links erbvij halen, ik heb nu geen tijd. Maar neem van mij aan dat ik niet lieg over dingen die makkelijk controleerbaar zijn, jij wel, je hebt dat al eerder gedaan, en morgen zal ik het aantonen, en indien niet zal ik nederig erkennen dat ik me vergist heb. Dus spaar je grote woorden even

  • 1 / 1

baseline op Donderdag 17 April 2008 16:21

image

Welke links ?
Echt genant gewoon.
Ik heb namelijk voorgesteld na de Ecma standaardisatie voorgesteld om de naam te wijzigen naar het Office Open XML

Je plaats hier weer een heel setje van persoonlijke aanvallen op mij zonder dat je de info goed hebt geverifieerd. Juist precies het omgekeerde het geval is namelijk dat ik mede heb gezorgd voor een meer neutrale naamvoering van het formaat juist omdat het niet onderwerp niet gaat over Microsoft, Ecma of ISO maar om het bestandformaat aan zich.

  • -2 / 2

toiletpaper op Donderdag 17 April 2008 21:31

image

Ik heb me toch verontschuldigd, vind je het dan toch prettig om na te trappen?

Ach, doe maar, ieder zijn eigen zwakheid, je laat jezelf wel kennen, dat is een nadeel, maar blijkbaar ehb je dat ervoor over. Het was inderdaad Alex Brown (the Alex Brown, de onpartijdige, de deftige ISO voorzitter die zich ergert aan onconventionele actievoerders, die even onconventioneel 800 issues liet afhameren, juist die Alex Brwon heeft even onconventioneel honderden edits in Wikipedia aangebracht) die de bewuste edits had aangebracht, niet jij. Ik had jullie twee verward, een keer fout klikken, en een vergissing is geboren.

  • 2 / 2

baseline op Vrijdag 18 April 2008 14:10

image

Ik zie inderdaadnu ergens halverwege een berichtje van je een excuus staan maar daaronder stond nog gewoon een bericht waarin je je volslagen onterechte beschuldigingen aan mijn adres voortzette.

Misschien moet je beter opletten voor je ongefundeerde publieke beschuldigingen jegens medereageerders doet die uiteindelijk volkomen onterecht blijken te zijn.

  • -2 / 2

toiletpaper op Vrijdag 18 April 2008 20:12

image

Misschien moet jij beter letten op de volgorde van berichtjes, en alweer trap je na, tjongejonge. Je hebt het echt nodig. Jammer, vooral voor jou.

  • 1 / 1

toiletpaper op Vrijdag 18 April 2008 20:14

image

je begint wel op een oud wijf te lijken, ik denk dat ik het hier maar bij laat.

  • 1 / 1

baseline op Zondag 20 April 2008 19:39

image

Jij noemt het natrappen, ik noem het rectificeren van jou pertinente en aangetoonde leugens over mij.

Je gedrag hier is bij het schandalige af.

Je beledigt hier mij in meerdere berichten op volstrekt onterechte gronden en je pathetische excuses zijn slechts verstopt in een berichtje waarin je dan maar even een gerespecteerd ISO commitee voorzitter en een lid van het engels britisch standards institute te beledigen. Hoe haal je het in je bolle hoofd of zo je excuses aan te bieden.

En het is echt het toppunt van treurigheid dat je na je beledigende leugens en pathetische excusesberichtje dat je hier dan nog even terugkomt om mij dan maar even te beschuldigen van natrappen en me een oud wijf te noemen.
Ongelooflijk zielig mannetje ben je toch.

  • -2 / 2

toiletpaper op Zondag 20 April 2008 22:55

image

gerespecteerd ISO commitee voorzitter en een lid van het engels britisch standards
Voor mijn part was hij de Queen herself. Deze beschrijving maakt van deze man geen beter mens.

Zeg jij dan maar wat ik onwaar over Alex Brown schrijf.
Zo'n man hoort zich niet in discussies te mengen op Wikipedia, en daarna te mopperen dat anderen dat wel in publieke discussie over de standaard gaan.
Ik denk dat het gedrag van deze man zeker zal worden meegewogen bij het onderzoek dat de EC doet naar de wederwaardigheden rondom dit standaardiseringsproces.


Ik heb nog nooit een dergelijk gedrag van een ISO committee voorzitter gezien. Jij wel?


Dan laat ik me graag voorlichten.

Als hij een beetje ISO bewustzijn had gehad, had hij het afhameren van de 800 issues geweigerd, en gezegd dat er minimaal nog een BRM zou moeten komen, of liever, het fasttrack-traject afgebroken.
Ik ga echter geen nieuwe discussie hier beginnen. Jij ook niet, jij laat het ook bij modder gooien.

  • 2 / 2

toiletpaper op Zondag 20 April 2008 23:14

image

De beste manier om mij gelijk te geven is wanneer binnenkort zijn edits op Wikipedia zijn verwijderd, of hij zijn nickname heeft gewijzigd.
Het lijkt mij niet onmogelijk dat gepoogd zal worden de geschiedenis aan te passen aan een meer gewenste versie.

  • 1 / 1

baseline op Maandag 21 April 2008 17:56

image

Zo'n man hoort zich niet in discussies te mengen op Wikipedia,

Er stonden tientallen volstrekte nonsense verhalen over het ISO proces (termijnen, stemrechten/verhoudingen, commitee samenstellingen en verwareende verschillne tussen JTC1 en SC34) en Alex Brown heeft zeer veel heel nuttige edits om het ISO fasttrack proces in de wikipedia artikelen te beschrijven. Altijd goed voorzien van referenties naar de betreffende ISO documentatie.
Dit was een zeer nuttige bron van informatie tijdens het ISO standaardisatie proces.

Dat jij denk dat hij als eerste de naam OpenXML aan het artikel heeft toegevoegd is gewoon je eigen dommigheid. Hij heeft na de BRM de lead intro zoals die er eerder stond gewoon teruggezet en er geprobeerd aan toe te voegen "ISO/SEC 29500" omdat ISO na de BRM bijeenkomst die nammgeving als officiele designatie gebruikt voor Office Open XML.

Er stond namelijk al voor zijn edit eerder OpenXML als naam in de lead:
Bijvoorbeeld: http://en.wikipedia.org/w/index.php?title=Office_Open_XML&oldid=197744869
en het is ook een naam die net als ooxml weliswaar geen officiele betekenis heeft maar die wel vaak gebruikt wordt. Dus als daar staat "often referred to as" is op zich gewoon terecht. Dat geeft namelijk een feitelijk correcte situatie aan.

Dat iemand van ISO in wikipedia op de juiste wijze het ISO proces heeft beschreven was gewoon zeer waardevolle bijdrage aan het artikel tijdens de standaardisatie. Dat was juist zeer aan te prijzen.

Verder heeft Alex tijdens zijn functioneren in het BSI commitee nog actief bijgefddragen aan het opsporen van issues met het formaat en is hij tijdens de meeste recente bijeenkomst van SC34 committee nog uigebreide complimenten gekregen, opgenomen in de ISO archieven, over zijn werk als convenor van de BRM bijeenkomst.
Ik heb iets meer respect voor iemand die zo actief en positief heeft bijgedragen aan het standaardizatie proces en goed vervullen van zijn taken daarin dan voor iemand als jij die na tien seconden wikipedia bekijken mensen die je niet kent veroordeelt. Bah.

Je zinkt met elk bericht dieper in een bad van vunzigheid die je zonodig over anderen wilt uitdelen.

  • -2 / 2

toiletpaper op Maandag 21 April 2008 21:04

image

Dat jij denk dat hij als eerste de naam OpenXML aan het artikel heeft toegevoegd is gewoon je eigen dommigheid.
Dat is simpelweg aantoonbaar, maar verder, ik zal niet zeggen dat al zijn bijdragen slecht of goed zijn. Er zaten van beide smaken bijdragen bij.
Hij dient zich vanuit zijn positie te onthouden van publieke discussie.

Nobless oblige

Dat heeft hij gemist, dus, gewoon afgang, een voorzitter onwaardig, dat is mijn mening

  • 2 / 2

toiletpaper op Dinsdag 22 April 2008 09:25

image

Je zinkt met elk bericht dieper in een bad van vunzigheid die je zonodig over anderen wilt uitdelen.
Als je met modder gooit moet je er altijd rekening mee houden dat je zelf ook wordt geraakt.

;-)

  • 1 / 3

baseline op Dinsdag 22 April 2008 11:08

image

Inderdaad.

En dat geldt zeker voor jou met je leugenachtige beschuldigingen richting mij en richting een gerespecteerd lid van de Britse standaards organisatie en met vervolgens een heel slap excuus gevolgd door nog wat extra beledigingen van jou kant.

En zolang jij hier blijft posten om je gelijk te halen terwijl je gewoon een leugenachtig stukje vuilnis bent waarvan het ongelijk al rtuim is aangetoond zal ik hier blijven reageren om te blijven herhalen dat jij hier op aangetoond onterechte grond hier personen zit te beledigen.
Die modder die jij hier met je leugens op dit forum hebt uitgestrooid pik ik niet en je patetische halve excuses accepteer ik volstrekt niet en ik zal hier die leugens voor je vooeten blijven gooien tot je ophoepelt.

  • -2 / 2

toiletpaper op Dinsdag 22 April 2008 11:44

image

Ik heb me verontschuldigd bij jou, en wat betreft gerespecteerde mensen, ik heb er zoveel fouten zien maken. he betekent niet zoveel als iemand gerespecteerd wordt genoemd.
Ik heb goed uitgelegd waaruit mijn kritiek op hem bestaat. Ik ga dat dit keer niet herhalen
ik zal hier die leugens voor je vooeten blijven gooien tot je ophoepelt.
;-)

interessante stellingname, misschien moet je eens professionele hulp zoeken

  • 2 / 2

toiletpaper op Dinsdag 22 April 2008 11:50

image

een gerespecteerd lid van de Britse standaards organisatie
Ik heb trouwens dit gedrag van Alex Brown aangemeld bij de EC, zodat ze in het onderzoek naar de gang van zaken rondom OOXML dit kunnen meenemen, indien ze het relevant vinden. opmerkelijk is het in elk geval.

  • 2 / 2

baseline op Dinsdag 22 April 2008 16:20

image

Goed plan anoniem klootzakje.
Iemand die net een eervolle vermelding heeft gekregen binnen ISO over zijn werk tijdens de Office Open XML standaardisatie aanmelden bij de EC omdat hij in wikipedia waardevolled informatie over de ISO procesvoering heeft toegevoegd.

Pure walging is alles wat ik nog voel bij jou zielige gedrag.

  • -2 / 2

toiletpaper op Dinsdag 22 April 2008 21:22

image

gek dat dat wederzijds is

  • 1 / 1

toiletpaper op Dinsdag 22 April 2008 21:23

image

vervangen door medelijden, als ik een seconde langer nadenk....

  • 2 / 2

toiletpaper op Dinsdag 22 April 2008 21:38

image

Ik blijf erbij dat een ISO convenor boven de partijen moet staan en risico's moet mijden. Dat is wat Alex Brown niet heeft gedaan. Dat is een slechte zaak. Want hij heeft bekend gemaakt wat hij onzin vindt en wat niet, en niet tijdens een vergadering, maar botweg gepubliceerd op een voor ieder toegankelijke website. met andere woorden, hij heeft meegewerkt aan discussies in een sfeer van stemmingmakerij, waarin participanten zijn beschuldigd van edit-wars en 3-reverts-rule overtredingen (dit wijst op niveau kleuterschool).
Hij heeft de vergadering van buitenaf beïnvloed. Dat is een slechte zaak. Het is heel goed dat de EC dit weet als ze alle facetten rondom de OOXML certificering wil begrijpen.

Daarnaast, als hij in die honderden reacties niets verkeerds heeft geschreven is er ook niets verkeerds gedaan, maar ik laat graag een ploegje ambtenaren van de EC dit uitzoeken, en dat hoop ik dat ze gaan doen.

Dus waarom jij hier walging moet voelen is mij duister, of het moet zo zijn dat jij vreest dat er onregelmatigheden worden aangetroffen die OOXML weer binnen de EC, en misschien zelfs binnen de ISO in diskrediet kan brengen. Want zoals jij weet kan er nog steeds tot over meer dan een maand vanaf nu beroep worden aangetekend tegen de certificering.

Maar als jij weet dat dit proces haarzuiver is verlopen, waarom haal je dan niet gewoon je schouders erover op?

Jij hebt er geenv ertrouwen in, dat is het probleem, en terecht.

  • 2 / 2

baseline op Dinsdag 22 April 2008 21:57

image

Aan de andere kant ben ik het niet die op leugenachtige wijze mensen op een publiek forum beschuldigt van zaken die ze aantoonbaar niet hebben gedaan en daarna verder gaat met beledigingen om zijn onvermogen aan te tonen.

Je bent leugenachtig tuig dat probeert personen die het niet met je eens zij persoonlijk te beschadigen met aantoonbaar onterechte beschuldigingen en dat kan en zal ik hier net zo lang herhalen als dat jij denk dat je dat wilt aanhoren.


  • -2 / 2

toiletpaper op Dinsdag 22 April 2008 22:22

image

Je bent leugenachtig tuig dat probeert personen die het niet met je eens zij persoonlijk te beschadigen met aantoonbaar onterechte beschuldigingen en dat kan en zal ik hier net zo lang herhalen als dat jij denk dat je dat wilt aanhoren.
je bent een stakker, en dat meen ik, maar ik begrijp dat verdere discussie met jou zinloos is (eigenlijk heb ik dat idee altijd al gehad, dus veel zal er niet veranderen)
Ik neem aan dat wanneer je in deze houding volhardt, en discussies blijft verstoren met grof taalgebruik en beschuldigingen die volkomen off-topic en kinderachtig zijn, dit consequenties voor je account kan hebben.

ALs dat niet zo zou zijn, dan heeft het consequenties voor Webwereld, want ik geloof niet dat het Nederlandse publiek dit erg interessant zal vinden.

  • 2 / 2

baseline op Woensdag 23 April 2008 07:55

image

Ik ben niet degene die met aantoonbare leugenachtige informatie in deze discussie probeert iemand die het niet met hem eens is persoonlijk te beschadigen zoals jij dat doet.

En vervolgens blijf je hier lekker hangen om mij en anderen nog wat door te beledigen. Dat kun je zelf heel makkelijk stoppen door dezwe thread te verlaten maar je blijft maar volhouden en bij mij is de druppel wel overgelopen van wat bepaalde mensen hier richting mij voor leugensachtigs zaken spuien en persoonlijke aanvallen doen. Jij in het bijzonder.

Jij geachtervolg, gestalk, jou beledigingen en jou leugenachtige bewering richting mij persoonlijk maken me fysiek misselijk. Ik ga dat echt niet langer pikken en als ik wat beledigingen naar je kop moet slingenr om je te laten ophouden met mijn comments te achtervolgen dan zal ik dat zeker doen. Dat is mijn ogen niets vergeleken bij wat jij mij persoonlijk voor schade probeer te berokkenen.

  • -2 / 2

toiletpaper op Woensdag 23 April 2008 09:10

image

Ik ben niet degene die met aantoonbare leugenachtige informatie in deze discussie probeert iemand die het niet met hem eens is persoonlijk te beschadigen zoals jij dat doet.
Ik heb me in een kleinigheid vergist, ik had beweerd dat jij in Wikipedia OOXML naar OpenXML had veranderd. Het bleek Alex Brown te zijn die dat had gedaan, niet jij.

Ik heb dit al eerder toegegeven, en nu dus weer. Als iemand zich vergist, en dat toegeeft, en zich ook nog verontschuldigt hiervoor, dat had ik ook gedaan, dan is het beschadigend om die persoon een leugenaar te noemen, en wat je nog meer zegt.

Het ontbreekt jou aan enig zelfbeeld, en je gedraagt je als een blinde fanaticus. Rode waas zou SED zeggen, als je van Linux had gehouden

En vervolgens blijf je hier lekker hangen om mij en anderen nog wat door te beledigen.
Ik vraag me werkelijk af wie er wie beledigt.
Je bent een waarachtige stakker. Ik bedoel dat niet als belediging, maar het is voor mij onmogelijk om nog een positief beeld over jou samen te stellen op dit moment.
Verder heb ik hier niks meer aan toe te voegen.

  • 2 / 2

toiletpaper op Woensdag 23 April 2008 09:44

image

lekker hangen om mij en anderen nog wat door te beledigen
Een psycholoog zou het woordje "lekker" in dit zinnetje onmiddelijk duiden. het zegt zoveel over jou, baseline, en zo weinig over mij

  • 1 / 1

edjez op Woensdag 23 April 2008 10:44

image

Het zou zo leuk beeld zijn als jullie zonder het te weten gezellig iedere donderdagavond in hetzelfde fitnesscentrum met elkaar aan het keuvelen zijn...en dat één van de twee dan per ongeluk vertelt wat z'n nick op Webwereld is....

  • 1 / 3

toiletpaper op Woensdag 23 April 2008 11:09

image

leuke film, maar baseline heft het neit alleen op mij, de hele wereld treft zijn grof taalgebruik,

Zie bijvoorbeeld zijn reactie hier, op de blog van "een gerespecteerd ISO commitee voorzitter en een lid van het engels britisch standards institute" waar hij begint met andere mensen voor "tiny brains" uit te maken.

www.griffinbrow...30-b8eb79735e1a


Het feit dat hij zich op meer plaatsen misdraagt is weer geruststellend, het is niet op mij persoonlijk, maar het is een soort generieke haat tegen de wereld, of het is een typisch geval van Gilles de la Tourette die bij wijze van proef is gestopt met zijn medicatie.

Gauw weer beginnen, zou ik zeggen.

  • 2 / 2

edjez op Woensdag 23 April 2008 11:26

image

Goed, hij is niet subtiel (om het maar zacht te zeggen). Maar verbazingwekkend vind ik z'n gedrag niet. Er is aardig geprobeerd om hem onderuit te halen en publiekelijk aan de schandpaal te nagelen en vervolgens raakt hij hier en daar z'n zelfbeheersing kwijt. Vervolgens ontstaat er verontwaardiging over z'n taalgebruik en dat verbaast mij dan weer.

  • -1 / 1

ArjenB op Woensdag 23 April 2008 11:33

image

Er zit een geschiedenis aan vast, maar hij doet het ook op andere fora. Zoek de gemeenschappelijke factor, denk ik dan in mijn eenvoud.

  • 2 / 2

toiletpaper op Woensdag 23 April 2008 13:00

image

Er is aardig geprobeerd om hem onderuit te halen en publiekelijk aan de schandpaal te nagelen
Ik had alleen per abuis gezegd dat hij de term OpenXML aan Wikipedia had toegevoegd, ik heb meermalen verklaard dat dit een vergissing was, en ik heb me ook meermalen verontschuldigd.
Op het moment zijn we zover dat Microsoft zelf de term OpenXML voert, en het woordje Office ervan af heeft laten vallen.

Enkele dagen geleden noemde hij een ander "dement".

Het is niet alleen op mij gericht, hij doet het bij iedereen die het niet met hem eens is. Kleineren.
Als je het mij vraagt, ben ik het met ArjenB eens.

Ook de consistentie waarmee hij het doet, een stuk naar boven hadden we een discussie voer ISO datum notatie, die begint hier: baseline 11-04-2008 08:02, wat me vervolgens in en discussie allemaal wordt toegevoegd? Ik geef toe dat ik zelf ook niet aardig ben, dat hoeft voor mij niet, maar wat hij mij, in een zuiver zakelijke discussie allemaal toevoegt: gênant, triest, belachelijk....
Het regent dit soort kwalificaties, op continue basis,

Ik kan het alleen maar als ziekelijk verklaren, en een van de ziektes die een dergelijk gedrag veroorzaken heeft een naam.

Nu genoeg hierover. Voor mij is het duidelijk.

  • 1 / 1

baseline op Donderdag 1 Mei 2008 13:09

image

Ik had alleen per abuis gezegd dat hij de term OpenXML aan Wikipedia had toegevoegd,

Ik had dat al ontkent en toen heb jij het nog eens herhaald en gezegd dat je wel met bewijs zou komen.
Waar het om gaat is dat jij het zodra je met argumenten nergens komt altijd op de man gaat spelen. Het is te gek voor woorden dat over het internet of zelf in wikipedia edits gaat zitten doorzoeken om iets te kunnen vinden wat je niet bevalt en dat hier gaat melden om te proberen mij in diskrediet te brengen.
Lachwekkend, genant en ook diep triest is dat je dan ook nog dat zodanig doet dat je de suggestie probeert te wekken dat ik zaken geschreven zou hebben die ik helemaal niet geschreven heb.

Jij zit met je anonieme steeds veranderende naampjes en accountjes weet mogelijk overal ter wereld Microsft en Office Open XML zwart te maken. Ik zie je daar best voor aan maar ik ga nog niet Google searches doen om je persoonlijk te achtervolgen over het internet en dan als je berichten of zelfs wikipedia edits te doorzoeken of ik daarmee iets kan vinden om je te beschadigen.
En om als je dan zelfs blijkbaar nog niks kan vinden om dan dan aankomen met valse beschuldigingen over zaken die ik helemaal niet geschreven heb is gewoon walgelijk.

  • -2 / 2

toiletpaper op Vrijdag 2 Mei 2008 19:38

image

gewoon walgelijk
inderdaad, dat is jouw taalgebruik, keer op keer

  • 2 / 2

toiletpaper op Dinsdag 22 April 2008 14:40

image

Office 2007 kan bestanden niet opslaan in ISO's OOXML-standaard

De bestandsformaten die Microsofts Office 2007 genereert, wijken behoorlijk af van de variant van Microsofts OOXML-standaard die is goedgekeurd door de ISO. Dat concludeert Alex Brown na een test met Office 2007. Brown, die voorzitter is van de werkgroep die de ISO-variant van OOXML onderhoudt, gebruikte daarvoor het Office 2007-document waarin de door ECMA geaccepteerde variant van OOXML staat beschreven; dat bestand is ongeveer 60 megabyte groot.

Bij een test tegen het 'strikte' conformiteitsmodel vond Brown 122.000 foutmeldingen; daarbij ging het voornamelijk om onherkenbare attributen of ongeldige attribuutwaarden.
Bij het overgangsmodel - dat beoogt een brug te slaan naar de ECMA-376-standaard en oudere XML-formaten - scoorde Office 2007 overigens een stuk beter; daarop vond Brown niet meer dan 84 afwijkingen.

Desalniettemin moet worden vastgesteld, zegt Brown, dat bestanden die worden aangemaakt met de huidige versies van de Office 2007-toepassingen niet voldoen aan de ISO/IEC 29500-norm voor OOXML-bestanden. Volgens Brown zal aanpassing van Office 2007 aan het strikte conformiteitsmodel nog wel het nodige werk vergen, maar hij hoopt wel dat Microsoft in het volgende service pack gerealiseerd zal hebben. (Jelle Wijkstra)

  • 3 / 3

baseline op Dinsdag 22 April 2008 16:39

image

Goh, iemand test documenten gemaakt in 2006 voor de standaardisatie van Office Open XML met de MS Office 2007 release candidate tegen de nog ongepubliceerde nieuwe strict schema's (strict schema's waarin veel item niet meer zijn opgenomen) uit het huidige ISO standaardisatie proces en vind dan 122.000 verschillen.

Gejuich natuurlijk bij de OSS community.
MS Office 2007 is niet strict conformant met een nog niet gepubliseerde ISO spec en schema's. MS Office is echter overigens natuurlijk wel conformant met de in 2006 gepubliceerde open standaard Ecma specificatie spec waar het naar ontwikkeld is.

Voor de echt geinteresseerden is het misschien dan ook wel leuk om te weten dat openOffice NOG NOOIT heeft geconformeerd aan enige versie van OpenDocument laat staan de ISO OpenDocument versie ook al is het al weer 3 jaar gelden dat OASIS die specificatie heeft geapproved en twee jaar dat ISO OpenDocument heeft geapproved.

Een bekend al eerder genoemd voorbeeld daarvan is dat OpenOffice een oude gemodificeerde versie van MathML ondersteunt (MathML v1.01 modified) terwijl de OpenDocument specification al drie jaar zegt dat in OpenDcoument MAthML 2.0 gebruikt moet worden.

Uit sectie 12.5 van de ODF spec:
Mathematical content is represented by MathML 2.0 (see [MathML])

Moet je dus nou echt juichen dat een oud document uit 2006 niet voldoet aan een nog niet gepubliseerde nieuwe spec of moet je niet eigenlijk huilen dat nieuwe openOffice documenten die je nu creert nog steeds niet weet te voldoen aan een drie jaar oude specificatie.

  • -3 / 3

Bolleke op Dinsdag 22 April 2008 21:13

image zomerhack badge 3

MS Office is echter overigens natuurlijk wel conformant met de in 2006 gepubliceerde open standaard Ecma specificatie spec waar het naar ontwikkeld is.
Ik neem aan dat je dat andersom bedoelt.

Voor de echt geinteresseerden is het misschien dan ook wel leuk om te weten dat openOffice NOG NOOIT heeft geconformeerd aan enige versie van OpenDocument laat staan de ISO OpenDocument versie ook al is het al weer 3 jaar gelden dat OASIS die specificatie heeft geapproved en twee jaar dat ISO OpenDocument heeft geapproved.
Klopt. En OOo != ODF. Een standaard is waar je heen wilt, niet waar je ooit geweest bent. Maar als MS en haar fans bij hoog en bij laag beweren dat backwards-compatibility zo'n sterk punt is, dan is dit feit over Office/OOXML natuurlijk wel - durf ik het te zeggen? Welja, vooruit: - genant.

  • 4 / 4

baseline op Dinsdag 22 April 2008 21:52

image

Ik begrijp niet wat je precies bedoelt.
Vind je het genant dat MS Office files valideren tegen het nieuwe ISO schema ?

Dat heeft namelijk niets met compatibliteit te maken. Het is namelijk heel eenvoudig onm de oude bestanden met 100% betrouwbaarheid te converteren naar het nieuwe transitional schema. De validatie fouten komen bijvoorbeeld door waarde wijzigingen (in het voorbeeld van de Ecam spec waren alle validatie fouten tov het transitional schema van dat type waarbij de waardes 'on' en 'off' veranderd in 'true' and 'false'. Dat lijkt me nog steeds verrassend makkelijk compatible te houden.

  • -3 / 3

Bolleke op Woensdag 23 April 2008 08:39

image zomerhack badge 3

Ik begrijp niet wat je precies bedoelt.
Vind je het genant dat MS Office files valideren tegen het nieuwe ISO schema ?
Af en toe vraag ik me af of we wel over hetzelfde onderwerp praten, baseline.

Laten we even iets vaststellen. Er is door MS (en haar aanhangers, waaronder jij) bij hoog en bij laag beweerd dat slechts OOXML goed genoeg zou zijn om 100% compatibiliteit met bestaande documenten te bieden. Dat argument is o.a. door ondergetekende met klem bestreden, maar dat is een ander verhaal.

Nu hebben ze eindelijk hun standaard, maar hun huidige Office pakket - wat jarenlang de de facto standaard is geweest, om allerlei hier ook niet ter zake doende redenen - ondersteunt die op dit moment niet. Dat betekent dat hoe je het ook wendt of keert, er tot het moment dat ze dat geupdate krijgen er allerlei intermediate formaten rond zouden kunnen gaan zwerven(*). Als ze er van tevoren beter over zouden hebben nagedacht en er niet zo'n haastklus van hadden willen maken dan was dat niet gebeurd. Op z'n minst lijkt het mij een zeer goede reden om met het gebruik van MS Office te wachten tot dit gefixed is, want anders zit je niet met 1 maar met 2 conversieslagen, en conversieslagen kosten een bedrijf typically een bak met geld (dus dat doen ze liever niet).

(*) gelukkig krijg ik van bijna niemand OOXML toegestuurd nog.

  • 4 / 4

Scheurleer op Woensdag 23 April 2008 09:20

image

Op z'n minst lijkt het mij een zeer goede reden om met het gebruik van MS Office te wachten tot dit gefixed is
Volgens mij haal je nu applicatie en opslagstandaard door elkaar. Ik neem aan dat MS Office bestanden ook nog in andere formaten (bijv. de eigen binaire formaten) kan opslaan (weet ik niet zeker, ik heb Office2007 nog niet gezien). Dan zou er dus op dat punt geen bezwaar zijn tegen gebruik van MS Office 2007.

  • 2 / 2

baseline op Woensdag 23 April 2008 14:54

image

Nu hebben ze eindelijk hun standaard, maar hun huidige Office pakket - wat jarenlang de de facto standaard is geweest, om allerlei hier ook niet ter zake doende redenen - ondersteunt die op dit moment niet.

Dat is gewon niet juist.
Micrsoft Office ondersteunt juist wel de huidige versie van de OOXML standaard.
Dat is namelijk de gewoon open standaard Ecma 376.
Die is compatibel en de spec zijn gewoon open
MS Office ondersteunt nog niet de toekomstige ISO versie die nog niet is gepubliceerd.
Ecma zal deze nieuwe ISO versie ook weer overnemen in de Ecma standaards catalogus en dan zal het vermoedelijk wel Ecma 376 v1.1 worden. (handig omdat Ecma standaarden itt ISO standaard altijd vrijelijk downloadbaar en kopieerbaar zijn)
Deze ISO versie is dus gewoon een opvolger en net zoals OpenOffice nu nog geen ODF 1.2. ondersteunt ondersteunt MS office nog niet de nieuwe ongepubliseerde ISO versie.

Echter de ISO versie is dus gewoon ook weer een volledig compatibele versie met de oude documenten net zoals de huidige Ecma 376 versie.

Wel is het zo dat in de nieuwe ISO versie veel elementen, die de compatibiliteit betreffen, in transitionele schema's zijn geplaatst.
Je zal dus de zeer hoge mate van compatibliteit alleen bereiken door de transitionele schema's te gebruiken. Om bestaande documenten te converteren of om te consumeren heb je dus de transitionele schema's nodig. Je kunt dus ook de hudige met Ecma 376 gecreerde documenten heel makkelijk 1-op-1 omzetten naar de transitionele ISO schema's. Die formaten zijn erg op elkaar lijkend zoals al blijkt uit het tesje van Alex Brown.
Nieuwe documenten kunnen dan straks als de ISO versie wordt geimplementeerd voortaan met strict schema's worden gecreerd en hoeven dan geen transitionele elementen te bevatten.

Dit levert als voordeel dat enkel document producerende applicaties geen last meer hebben van transitionele elementen en dat consumerende applicaties kunnen kiezen of ze transitionele documenten nog willen ondersteunen of niet. Grote suites waarmee je geconverteerde documeten wilt lezen zullen dat misschien nog wel doen maar kleinere en meer specialistische implementaties zullen veelal geen ondersteuning hebben voor oude geconverteerde documenten en enkel met nieuwe documenten werken.

  • -2 / 2

toiletpaper op Dinsdag 22 April 2008 21:18

image

iemand test documenten
Een paar uur geleden heette hij nog: "een gerespecteerd ISO commitee voorzitter en een lid van het engels britisch standards institute"

en nu hij wat doet wat jou niet aanstaat is hij "iemand"?

Het gaat wel over dezelfde persoon: Alex Brown

ga toch fietsen, hoe kun jij nog serieus genomen worden?

  • 3 / 3

baseline op Dinsdag 22 April 2008 21:59

image

Raak je een beetje overspannne of zo. Het zijn niet de testjes van Alex waar ik me aan erger maar aan jij bent degen waar ik me aan erger.
Jou foute interpretatie van de zaken en vooral natuurlijk jou false beschuldigingen om mij in diskrediet te brengen

Dat staan mij niet aan !!

  • -3 / 3

toiletpaper op Dinsdag 22 April 2008 22:17

image

Raak je een beetje overspannne of zo.
Nee, ik raak niet overspannen (die indruk heb ik meer van jou, lees maar eens terug, echt ontspannen kan ik jouw reacties niet noemen), maar als jij een reactie begint met
"iemand test documenten",
dan is dat toch wat anders dan als er staat:
"een gerespecteerd ISO commitee voorzitter en een lid van het engels britisch standards institute test documenten"

Iedereen, behalve jij, blijkbaar, zal dit verschil begrijpen

  • 3 / 3

baseline op Woensdag 23 April 2008 00:35

image

Het commentaar over Alex dat Alex een gerespecteerd voorziiter was hield verband met zijn acteren als ISO lid en convenor van de BRM waar jij kritiek op had terwijl het ISO committee dat zich bezig houdt met Office documenten hem daar juist officiele erkinning voor gaf. Je genante actie om hem bij de europese commissie te melden terwijl juist algemeen zeer positief is gereageerd op zijn behandeling van de Office Open XML BRM.

Dat is een soort actie om jezelf belachelijk te maken zeker als je dat hier nog trots op jezelf gaat zitten verklaren.

Vervolgens haal je een artikel aan waar het een testje betreft waarbij een bestaande Ecma spec Office open xml document test bekijkt bij validatie tegen de nog niet gepubliceerde ISO spec. Dat is een expertise kwestie en het karakter of zelf wie de test heeft uitgevoerd is nauwelijks ter zake doend. Het gaat om kale feiten en jou interpretatie ervan.
Blijkbaar verwacht je dat een document uit 2006 conformant hoort zijn aan nog niet gepubliceerde toekomste specs in 2008.
Dat geeft veel inzicht in je overdreven negatieve houding tov Microsoft. Alsof Microsoft een paar dagen nadat de BRM bijeenkomst, waar nieuwe wijzingen zijn gecreerd en waar wijzingen in de ISO spec zijn geapproved, al zijn volledige office suite zou kunnen hebben aangepast zelfs nog zonder dat er door ISO officiele validatie schema's zijn gepubliceerd.

  • -3 / 3

toiletpaper op Woensdag 23 April 2008 09:04

image

Dat is een soort actie om jezelf belachelijk te maken
het spijt me, maar hier reageer ik niet op.... er is er in mijn ogen maar een die zich belachelijk maakt

  • 4 / 4

baseline op Donderdag 1 Mei 2008 12:35

image

Heb je ook zijn latere post gelezen
OpenOffice.org produceert geen standard ISO OpenDocuments

Niet alleen blijken OpenOffice documenten niet te valideren tegen de al twee geleden goedgekeurde ISO standaard maar er blijkt ook nog eens een kritisch fout te zitten in de XML validatieschema's van de OASIS website waardoor XML validators al fouten constateren in de validatiesschema's voor dat ze toekomen aan het valideren van de documenten.

Kortom, de standaard bevat nog kritische fouten (heeft niemand die schema's ooit uitgetest ???) en de OpenOffice.org 2.4 implementatie is niet conform de bestaande ISO standaard.

  • -2 / 2

baseline op Donderdag 1 Mei 2008 13:14

image

Hmmm, er is iets weggevallen.
OpenOffice.org is dus niet conformerend met het ISO/IEC 26300 OpenDocument formaat dat twee JAAR geleden is gestandaardiseerd. (De ISO standaardisatie van Office Open XML daarintegen is nog niet eens afgerond)

  • -2 / 2

toiletpaper op Vrijdag 2 Mei 2008 19:20

image

dacht je, ik wacht een week met mijn reactie, dan kan ie er ongemerkt bij. Mr Right had dezelfde tactiek.


Leuk.

  • 2 / 2

toiletpaper op Vrijdag 2 Mei 2008 19:48

image

Kijk, de ISO standaard is ODF 1.0.

OpenOffice 2.4 is wat verder vooruit, die Alex Brown is jammer genoeg niet in staat om de dingen zuiver te houden. Het is ook niet zijn vak. Jij trouwens ook niet, dat je dat niet opvalt. het is jammer dat jij Alex Brown moet aanhalen om uiteindelijk er compleet naast te zitten.

Je kan in OpenOffice bewaren volgens de ISO ODF standaard. Maar die ISO standaard biedt minder features dan het documentformaat dat OpenOffice 2.4 gebruikt, en dat later dit jaar wordt voorgedragen voor certificering door ISO.

Een normaal proces. ISO standaarden zijn geen eindpunten, maar beginpunten. Ze hebben versies.

Je zal echter begrijpen dat ik in deze discussie die zo vol met vuilspuiterij zit, ik niet veel effort wil stoppen. ik zag toevallig dit misverstand van jou staan, en wilde het even uitleggen, dat is alles.

Ik wens je een prettig weekend toe, en ik raadt je aan om niet te agressief op webwereld te zijn, het wordt mooi weer. En agressie is toch wat anders dan gelijk hebben.

Succes en prettig weekend!!!

  • 2 / 2

Om te kunnen reageren, dient u ingelogd te zijn.

Nieuwsbrief

Ontvang dagelijks een overzicht van het laatste ICT-Nieuws in uw mailbox

Peiling

Loading Poll

Video: World Tech Update: Darpa's robot oorl...

World Tech Update: Darpa's robot oorlogspaard (video)

Verleden nieuws