Gepubliceerd: Zaterdag 23 mei 2009
Sinds kort ondersteunt Office 2007 ODF, maar formules voor spreadsheets werken niet. Wie blaast open standaarden op?
Toon volledig artikel
Tjonge, zijn er drie artikelen aan gewijd en nog zit dit artikel vol met fouten.
Een voorbeeldje
Veel andere pakketten werken momenteel met versie 1.2 van de standaard, waarin de ontbrekende functionaliteit wel is toegevoegd.
A) Versie 1.2 is nog geen versie van de standaard maar is een draft versie. Een toekomstige versie van de standaard
B) Er is maar 1 pakket die met een versie 1.2 van ODF werkt en dat is OpenOffice 3.x . Vrijwel alle pakketten werken met OASIS ODF 1.0/1.1
Versie 1.2 is nog geen versie van de standaard maar is een draft versie.
Zie je het zelf ook? Een draft versie is toch echt een versie van de standaard.
Lijkt me toch niet maar als je dat vind prima.
Partijen die vragen om ondersteuning van de standaard bedoelen over het algmeen geen ondersteuning van een draft versie.
Alleen de W3C als uitzondering publiceert hun drafts als laatste versie van een standaard.
Bij een standaardisatie OASIS die ODF onderhoudt staan de drafts niet vermeld bij de informatie over de ODF standaard versies en je moet dan dus echt in het documentarchief van het committee op zoek naar de draft versies.
Hier de lijst van alle OASIS standaardversies
http://www.oasis-open.org/specs/
Het gaat er niet om wat de markt vraagt.
Het gaat er hier om dat je claimt dat een draft versie van een standaard geen versie is van een standaard. Het is evident dat een draft versie een draft *versie* is van een standaard.
Dus een versie is alleen een versie als het definitief is? Een voorlopige versie mag geen versie heten? Ik stel voor dat je wereldwijd voorstelt om alle alpha, bèta, release candidate en draft versies vanaf nu aan te duiden met ... uitgave? Je zegt het maar.
Waarschuwing: DNFTT
Letterlijke quote van Dosprompt:
Als ik de idioten hier serieus moest nemen zou ik me weer gaan ergeren aan de minnetjes. zolang er geen normlaa moderatiesysstem op Webwereld is kan ik me hier wel wat uitleven.
Het gaat Albert niet om de discussie maar om het 'uitleven'.
Goed voorbeeld.
Ook bij RFC's zijn er namelijk drafts en die hebben nog niet de status van een RFC.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are not an archival document series. These documents should not be cited or quoted in any formal document. Unrevised documents placed in the Internet-Drafts directories have a maximum life of six months. After that time, they must be updated, or they will be deleted.
De IETF net als OASIS of ISO of IEC of Ecma of ANSI en eigenlijk vrijwel elke andere standaardorganisatie presenteren hun drafts niet als versie van de standaard maar als werkdocument met een tijdelijk status. Je kunt bij deze organisaties historisch eigenlijk vaak alle versies vande standaard terugvinden maar draft versies niet tenzij in een werkdocumente archief.
Ik vind het dus niet zinvol om een draft versie als een versie van de standaard te omschrijven. Dat is verwarrend en wekt ten onrechte de indruk dat draft versie een status hebben van een door verschillende partijen geaccordeerd document wat versie van standaarden effectief wel zijn.
Zoals je zelf ook al ergens bevestigde is een standaard met name ook datgene waar consensus over is om het te gebruiken.
Waarom ik er in dit kader belang aanhecht is dat er een issue is met de benaderring van OOo omdat zij niet vastleggen wat ze wel of niet ondersteunen. Niemand weet welke draft(s) er aan de basis lagen van OOo 3.0 en welke toevoegingen uit recentere drafts er in versie 3.1 zijn toegevoegd (er zijn bijvoorbeeld formules aangepast vermoedelijk op aanpassingen in openformula). Bovendien zijn de huidige document versie van OOo 3.0 en 3.1 niet onderscheidbaar van toekomstige standaard versies. Als er in de reviews nog een issue gevonden wordt in bijvoorbeeld Openformula dan wordt het een issue of men dat nog aan gaat passen omdat het issue ook al aanwezig kan zijn in bestaande documenten en dat blijft het mischine zitten tot ODF 1.3 (over weer 4 jaar ?) omdat men de huidige bestaande bestanden niet incompatible wil maken.
Door het kiezen van een vooruitlopende strategie gebaseerd op draft versie wordt het standaardisatie proces behoorlijk gehinderd. En dat geld niet alleen voor OpenOffice met ODF maar ook voor MS Office en Office Open XML. Wat MS Office implementeert aan Office Open XML bepaald de standaard meer dan de specificatie. En nu doet OOo bij ODF in feite hetzelfde.
Misschien is dat ook wel de reden geweest voor de vroege implementatie. Hierdoor voorkomen ze dat andere partijen een interpretatie van ODF 1.2 bouwen die niet overeenstemt met hun eigen implementatiekeuzen.
De ironie wil dat deze zekerheid voor het gesloten .doc- of .xls-formaat wel groot is, omdat het zowel door Microsoft Office als OpenOffice.org goed wordt ingelezen en weggeschreven.
En dat klopt dus niet, mijn kinderen kunnen geen OpenOffice gebruiken voor hun schoolverslagen omdat de opmaak vernaggelt wordt wanneer ze de bestanden uitwisselen met medeleerlingen die ms-office gebruiken.
Dat soort problemen zijn er met onderlinge versies van MS Word ook. Als je verslagen maakt dan moet je voor dat de stukken worden samengevoegd nooit opmaak voor gebruiken. In het verleden heb ik het altijd op die manier gedaan.
Toen mijn studiegenoten hard genoeg aan het vloeken waren op de plaatjes in MS Word heb ik laten zien hoe het in OOo kan. Sindsdien heel wat mensen aan OOo geholpen.
Er wordt ook gerefereerd aan een test van het ODF alliance maar die hebben helemaal niets getest maar alleen wat blogposts opgezocht en daar een 'fact sheet' uit geproduceerd.
Bovendien bevat de fact sheet informatie die Microsoft al maanden lang on line heeft staan in hun implementatie notes van ODF zoals het (nog) niet supporten van encrypted ODF files.
Ik vraag me trouwens af hoeveel fact sheets het ODF alliance in de afgelopen 3 jaar heeft gemaakt over de mate van support in andere ODF implementaties zoals OOo. Aan de andere kant hebben die implementaties ook nergens informatie on line staan over welke features in ODF ze wel of niet supporten.
alleen wat blogposts opgezocht en daar een 'fact sheet' uit geproduceerd.
Weer eens te hard gezogen op je iets te dikke Albert duim?
Peter,
Gaaf als je iedere keer begint te roepen "DFTT", maar zelf wel ingaat op de reacties van Albert.
Vind je de reacties misschien toch interessant?
Hoe leuk het ook is dat er een open standaard is, de standaard die open is (ODF 1.1) is gewoon niet af/volledig.
Zelf OOo beaamt dat indirect door hem zelf niet standaard meer te gebruiken. Als MS nu ODF 1.2 gaat toepassen zullen ze OOo moeten volgen in de implementatie. Anders worden ze Acuut beschuldigt hun eigen afgeleide te creëren.
Ik Hoop dat de ODF 1.2 volledig wordt, goedgekeurd wordt en door MS ondersteund gaat worden. (Een goede manier om de SUN plugin aan de man te brengen is mischien nog wel beter)
ps. Zelf gebruik ik al z'n 5 alleen maar OOo
Dat klopt, daarom komen er ook nieuwe versies. Aan de ODF 1.1 zal geen support voor formules worden toegevoegd, die zullen in ODF 1.2 komen.
De standaard ODF 1.1 is daarom volgens mij niet compleet. Zoals het er nu naar uit ziet zal ODF 1.2 een stuk completer zijn.
En dan maar hopen dat MS die dan (ook) gaat ondersteunen.
MS ontkomt er niet aan om elke toekomstige versie te ondersteunen, MS zal alleen niet laten het proces zo lang mogelijk te traineren.
Ergens hebben ze het gelijk mee en aan de andere kant verliest MS het in de opinie, het is een spagaat voor MS.
Goede ondersteuning verzwakt de Open standaard positie van OOXML, slechte(re) ondersteuning betekent gezichtsverlies en kritiek met maar een (klein) kansje dat hun eigen formaat meer in zwang raakt.
Het is dan alleen of de "alternatieven" niet met dezelfde redenering hun ondersteuning geven, OOXML is immers ook nooit "klaar".
Het bewijst alleen opnieuw dat twee open standaarden niet een gewenste situatie is, voor en tegenstanders hebben nu altijd een reden en excuus om elkaar dwars te liggen, en naar mijn (bescheiden) mening heeft MS deze "oorlog" nu gestart, maar waar eindigt deze.
4. Wat werkt nu wel?
Dat is een lastige vraag. Over ODF wordt gesteggeld en de echt werkende versie van het formaat is duidelijk versie 1.2 dat nu niet in alle officepakketten lekker werkt. Gelukkig kunnen gebruikers van Office 2007 wel de plugin van Sun Microsystems gebruiken, maar kunnen daarvoor niet op ondersteuning van Microsoft rekenen. Belangrijk is wel dat de extensie ervoor zorgt dat overstappen op een andere leverancier daarmee wel mogelijk blijft
Versie 1.2 van ODF werkt nog helemaal niet interoperabel.
Alleen OOo 3.x ondersteunt versie 1.2 en OOo heeft bijvoorbeeld tussen versie 3.0 en 3.1 de openformula formules die nog in ontwikkeling zijn aangepast.
Bijvoorbeeld IBM Symphony zal pas ODF versie 1.2 implementeren in 2010 en MS Office vermoedelijk niet eerder dan 2011
Versie 1.2 van ODF werkt nog helemaal niet interoperabel.
Correct. Hoe verbazend is het, als jij dat wel inziet, dat Microsft dat niet ziet aankomen en nu de vermoorde onschuld speelt? Eigenlijk geef je dus ook toe dat Microsoft hier een politiek steekspel heeft gespeeld, met als enige doel ODF te beschadigen.
Versie 1.2 van ODF werkt nog helemaal niet interoperabel
Correct. Hoe verbazend is het, als jij dat wel inziet, dat Microsft dat niet ziet aankomen en nu de vermoorde onschuld speelt?
MS heeft toch die 1.2 versie niet geimplementeerd. Ze hebben al meer dan een jaar geleden gezegd dat ze ODF 1.1 zouden implementeren en hebben dat nu gedaan. Iedereen heeft ODF 1.0/1.1 geimplementeerd, alleen OOo is op de boel vooruitgelopen.
Het is volstrekt onduidelijk waarom OOo heeft besloten heeft een draft versie van ODF 1.2 te implementeren terwijl voltooing van die draft en daarop volgende standaardisatie nog 1-2 jaar in de toekomst zou liggen.
Jij geeft zelf aan dat 1.2 nog niet kompleet is. Van de vorige versie was ook bekend dat die niet kompleet is. Het gemis van de formules was al vrij vroeg duidelijk.
Die twee overwegend, is het 100% duidelijk dat Microsoft haar uiterste best heeft gedaan om een inkomplete standaard te ondersteunen voordat de nieuwe versie van die standaard wel kompleet zou zijn.
Want met een komplete versie 1.2 zou Microsoft geen zinnig verweer meer hebben waarom ze er een rommeltje van maken.
Het lijkt me dat een kind dat tot twee heeft leren tellen deze optelsom kan maken. Het 'vermoorde onschuld' spel van Microsoft is dan ook lachwekkend ongeloofwaardig.
Je redenatie ontgaat me.
Het implementeren van een formaat heeft niks met compleet zijn te maken.
Voor MS zal relevant zijn of klanten het willen hebben of vereisen.
Er is nog niemand die ODF versie 1.2 vereist en dat zal voorlopig ook niet gebeuren verwacht ik
Het implementeren van een formaat heeft niks met compleet zijn te maken.
Ah, dus je begrijpt jet eigenlijk wel, hAlbert ;-)
Er worden veel meer "drafts" voortijdig geïmplementeerd, bijvoorbeeld WiFi, naast a, b en g is de, nog steeds draft, n al door veel fabrikanten ingevoerd.
Voor MS zal relevant zijn of klanten het willen hebben of vereisen.
Er is nog niemand die ODF versie 1.2 vereist en dat zal voorlopig ook niet gebeuren verwacht ik
hAldraai alert, "klanten het willen hebben of vereisen"
Klanten zullen het best "willen hebben", maar "vereisen" is er niet bij, althans niet anders dan de hand op de knip houden...
M$ kan haar oude "verdeel en heers" tactiek nog niet loslaten, en "hoopt" zo ODF te frustreren ten voordele van OOXML.
En je "verwacht ik" spreekt weer eens boekdelen, je hebt duidelijk je pro M$ pet weer op. (maar dat verbaasd me niet, elders ben je, onder je oude naam, nooit gestopt met je M$ "promotie")
Ook laat Office 2007 weinig heel van bullets en font-informatie
Het is onduidelijk waar dit vandaan komt.
Ik hebt net even in Writer een ODF documentje met een paar bullets en numbering gemaakt met twee verschillende fonts en dat opgeslagen, geopend in MS Office en daar weer als ODF opgeslagen en weer geopen in writer en ziet het er nog precies hetzelfde uit qua bullets,numbering en fonts.
In MS Office zien de bullets er wel iets anders uit maar dat lijkt me niet echt een probleem omdat de info in de roundtrip terug naar OOo toch hetzelfde blijft.
Het is een bevinding van Marino Marcich, directeur van de ODF Alliance.
A document created in one ODF-supporting application, when resaved in Microsoft Office 2007, rendered differently – missing bullets, page numbers, charts and other objects, changed fonts – making collaboration on an ODF file with Office 2007 very difficult.
Maar ik denk dat hij er, als directeur van de ODF Alliance, te weinig verstand van heeft om dit te kunnen beoordelen. Hij zal het wel ergens uit een blogje geplukt hebben, denk je niet ook? Een halfbakken test van jou is een stuk geloofwaardiger.
Mede gezien het feit dat je laatst ook al zo'n moeite had met die Word exploit, denk ik dat je een zeer ervaren tester bent.
Het door het ODF alliance gepubliceerde factsheet maakt geen vermelding van issues met bullit en font en het ODF alliance publiceert ook geen test waaruit zoiets blijkt. Ik wil dus de bewering in het artikel ten minste aan een testeje onderwerpen.
Ik sluit niet uit dat er een foutje zit in de implementatie van MS Office (of zelfs OOo) maar dan is het wel handig te weten in welke situatie. Nu staat het er in bovenstaand als een algemene claim en uit mijn heel beperkte testje blijkt in ieder geval dat het zeker geen algemeen verschijnsel is. Ik volg minsten 10 of 12 blogs over Office documenten ook daarbij van IBM en Sun/OOo en op geen enkele daarvan zie ik de in bovenstaand artikel genoemde problemen met bullet en fonts terwijl daar wel andere zaken zijn besproken.
En ik verwacht ook best dat er nog meer incompatibliteiten gevonden worden. Ik zie ook regelmatig incompatibiliteiten tussen OOo en KOffice en Gnumeric die ik allen op mijn computer heb staan (en ook veel issues met Google docs) maar daar worden geen factsheets over gepubliceerd door het ODF alliance.
Het is niet evident dat puur met een beperkte specificatie alle implementaties ineens complexe office bestanden identiek renderen. Zeker als het interne document model van applicaties afwijkt is dat niet evident.
Het is een bevinding van Marino Marcich, directeur van de ODF Alliance
Dat is toch geen serieuze opmerking hoop ik.
Dank je dat echt of verzin je nu maar wat.
Het staat op de contact pagina van de ODF Alliance, dus ik gok dat er een kern van waarheid in zit, denk je niet ook?
Marino Marcich
Managing Director
ODF Alliance
Het is een bevinding van <naam>, directeur van de ODF Alliance
Dat is toch geen serieuze opmerking hoop ik.
Dank je dat echt of verzin je nu maar wat.
Alsof Ballmer een bevinding zou doen in OpenOffice zeg maar
Bedoel je dat Ballmer nooit iets beweert wat uit testen naar voren is gekomen?
Dus als hij beweert dat Windows 7 een verbeterde Vista is, dan moet ik aannemen dat hij terplekke aan zijn duim staat te zuigen omdat hij dat zelf niet getest heeft? Je gedachtewereld wordt me steeds vreemder. Sterker nog, ik kan het echt niet meer volgen.
@Dosprompt: Nee, dan noem je het trollen. Je gaat er maar lekker mee door, ik bekijk de schade morgen wel weer.
dosprompt mag rustig de advocaat van de duivel spelen, hoe vreemder en dieper hij zinkt om aan argumenten te komen hoe harder hij het bewijs levert dat MS niet deugd. Bij een deugdelijk bedrijf moet het helemaal niet moeilijk zijn pluspunten en goede argumenten te vinden, het lijkt dus bij MS steeds moeilijker deze pluspunten en argumenten te vinden.
Volgens mij vallen de argumenten van de tegenstanders van MS juist heel zwak uit.
MS heeft gewoon in een allerleerste relase van hun ODF formaat ondersteuning een behoorlijk standaard conforme versie van ODF neergezet en heeft daarin de propriety OOo spreadsheet formules vervangen door een ISO gestandaardiseerde versie die andere ODF applicaties als Gnumeric en KOffice al wel aankunnen.
OOo en IBM's Symphony die uit de zelfde code base komen hebben na 3 jaar nog geen validerende ODF versies en zijn bovendien ook nog eens incompatibel met elkaar nu OOo een door Symphony niet herkende namespace gebruikt.
Dat MS Office niet zo interoperable is qua spreadsheets met OOo en Symphony vind ik minder erg dan dat Sun en IBM die intens samenwerken in de ODF TC niet eens onderling interoperabele versies kunnen uitbrengen.
Bovendien heeft Microsoft als enige goede documentatie verstrekt over hun ODF implementatie en is dat bij ODF voorlopers OOo en Symphony helemaal niet het geval. Zo kun je in een OOo document nog steeds allerlei OOo specifieke document setting tegenkomen zoals "UseFormerLineSpacing" of "UseFormerObjectPositioning" zonder dat OOo gedocumenteerd heeft wat dat betekent.
Het gemekker over MS Office 2007 SP2 is vooral over het feit dat MS niet gekozen heeft om een niet standaard OOo formaat in te bouwen (dat OOo zelf trouwens al heeft gedumpt) maar in plaats daarvan een ISO standaard formaat heeft gebruikt.
Ik vind het het bepaald geen zwakte maar eerder een goede keuze. De op MS Office gebaseerde ODF spreadsheets zijn in iedergeval in een standaard vastgelegd en de implementatie is aanvullend gedocumenteerd voor interoperabiliteit.
Zaken die OOo nog nooit voor elkaar heeft gehad.
Microsoft heeft gewoon het recht dat te doen, of het verstandig is weet ik niet.
Standaarden in wording, en zeker zo complex als deze, kunnen alleen door onderlinge samenwerking tot stand komen.
Elke houding die MS ook aanneemt zal scherp beoordeelt worden omdat het verleden MS elke keer zal inhalen.
Het lijkt mij verstandiger van MS om meer de openheid te tonen die ze aangeeft te willen. Niet als een dwars kind een eigen koers te varen.
MS wordt nu eenmaal zéér kritisch bekeken, de meeste gebruikers hebben er geen idee van wat er speelt en zitten nu eenmaal op Windows en zeer velen op MSO. De wens van MS is ze daar te houden en daar doet een ODF met alternatieve pakketten nu eenmaal niet aan meewerken.
Peter,
Heb je de test van Albert zelf ook even geprobeerd?
Niet voor het een of ander, maar ik heb het hier even geprobeerd en had mijn 'probeersel' toch echt dezelfde uitkomsten.
Er werd bij mij dus niets verminkt.
Krijg ik van een ieder nu net zoveel minnetjes?
Sommige mensen hebben misschien liever een imaginaire test die zogenaamd aantoond wat ze graag wil horen.
Een ander persoon maakt er melding van dat ze ook slecht kunnen werken
Het artikel spreekt van een test waaruit dat zou blijken. Die lijkt er gewoon niet te zijn of wordt wel erg verborgen gehouden.
Het artikel en het persbericht van het ODF alliance stellen dat bullet en fonts niet werken maar zonder enige onderbouwing of in welke situatie zich dat voor zou doen of wat de oorzaak daarvoor zou kunnen zijn. Het fact sheet vvan het ODF alliance laat die claim echter volledig weg.
Het is dan niet gek dat ik dat zelf even probeer en direct al kan consteren dat in de basis de ondersteunign van fonst en bullets in MS Office ODF implemntatie gewoon correct werkt.
Waarom laat het ODF alliance die claim in hun officiele publicatie weg ? Komt het slechts in extreme situaties voor of is de oorzaak gelezen niet slechts in MS Office maar ook juist in een ander product en komt dat het ODF alliance publicitair niet uit ?
Let wel dat bullets en font ondersteuning, elementen die in misschien wel 80% van de Office documenten een rol spelen, veel signicanter zijn dan ondersteuning voor bijvoorbeeld encrypted ODF files die zeldzaam zijn maar waar de ODF alliance wel ophef over maakt.
Ik vind dat dus van belang om te weten maar ik mis nog steeds enigerlei informatie over de eventuele genoemde issues en kan niet eens bevestigd krijgen of de genoemde issues er uberhaupt wel zijn.
Microsoft speelt hier zoals zo dikwijls het machtsspelletje, met de dubbele bodem, zoals ik al zo dikwijls heb gezegd.
Tegelijkertijd bewijst dit nog maar eens dat het "maken" van standaarden nonsens is - standaarden ontstaan uit zichzelf doordat ze door een grote groep mensen gebruikt worden...
Mav.
En dat noem jij een valide test om conformance te testen?
Ik kan geen test van het ODF alliance vinden. Ik heb dus zelf maar een testje gedaan dat niet evident een probleem toont. Als jij testresultaten hebt die een probleem aantonen dan wil ik ze wel zien. Dan kan ik ook de oorzaak bekijken en bijvoorbeeld welke ODF versies er getest zijn.
Het ODF alliance factsheet bevat ook expliciet die in dit artikel genoemde issues met bullet en fonts niet.
Waarom niet ? Basic rendering van documenten lijkt me boeiender dan een relatief weinig gebruikte feature als de ondersteuning van encrypted ODF files waar nu het ODF alliance wel ophef over maakt.
Een probleem wat niet door jouw test wordt aaangetoond bestaat evident niet?
Dat stel jij nu.
Ik zeg dat nergens en ik stel voor dat je dat ook niet probeer te suggereren.
Misschien is Peter Koopman zo vriendelijk om je naar de betreffende test te linken als je erom zou vragen
Dan zou er wel zo'n test moeten wezen natuurlijk en de kans is vrij groot dat ik dat bestaan van dergelijke testresultaten een stuk eerder zou weten dan iemand anders hier.
Je doet een non-test om hem ongelijk te geven, en dat is een zwaktebod.
Een volstrekt belachelijk opmerking omdat ik helemaal niet op hem reageerde maar juist hij op de reactie over mijn testje.
Je moet niet proberen de feiten om te draaien.
In plaats van zaken te suggeren die ik niet gezegd heb en daar dan een eigen interpretatie op maken zou je er beter aandoen om de daadwerkelijk gemaakte claims van anderen eens onder de loep te nemen.
Het Webwereld artikel stelt dat er een test door het ODF alliance is gedaan waar zij bevindingen op baseren maar nergens is er sprake van een test van het ODF alliance en zij zelf beweren dat trouwens ook nergens. De claim van een test in het bovenstaande artikel is nergens aantoonbaar en de ODF alliance is echt niet zuinig met het strooien van anti-MS informatie dus die zouden maar wat graag testresultaten publiceren om hun gelijk te bewijzen.
Je ziet hier te hakken op een testje van mijzelf maar ik kan hier gewoon de resultaten zien en zolang er niemand met iets beters komt moet ik het daar maar gewoon mee doen. Ik geloof voorlopig niet dat er een test aanwezig is van het ODF alliance zoals Webwereld beweert. Dergelijke evidente simpele feiten als de ondersteuning van fonts en bullet zouden zeker ook door tientallen, zo niet honderden andere meteen als in de eerste paar dagen gemeld zijn na de MS Office release.
Iedereen kan trouwens ook zelf even een mini testje doen.
Het is jammerlijk dat iedereen denkt te moeten hakken op iemand die zeer gerede twijfels bij de artikel informatie kan stellen terwijl de onderbouwing vna het arti9kel zo0ndermeer afwezig is. Misschien wil iedereen graag horen over implementatie fouten in MS Office en worden dergelijk claims zonder meer als waar aangenomen maar ik wil graag iets meer zien dan wat losse claims.
En zoals ik al eerder zei is het zeker nog te verwachten dat er bepaalde bugjes gevonden worden in de verschillende OOo implementaties waaronder ook MS Office. Het zou belachelijk onwaarschijunlijk zijn als MS bij de implementatievan een complex document formaat in de eerste release een totaal foutloze implementatie zou hebben neergezet.
En zeker in de implementatie van grafische object, invoegobjecten en tabellen zou ik nog behoorlijke afwijkingen tussen de verschillende implementaties verwachten. De ODF standaard beschrijft veelal syntax en geeft juist op die visuele elementen vaak weinig info over rendering/positionering.
Dus ik zou juist graag een echte serieuze test van die verschillen willen zien maar ik verwacht geen serieuze test van een club als het ODF alliance en laat een deel van hun claims dus voorlopig voor wat het is.
Ik vind dat ook niet meer dan logisch.
Het lijkt me ook een groot verschil of een partij een doelbewuste keuze maakt voor het toevoegen van een feature of dat de feature fouten bevat.
Het ondersteunen van bijvoorbeeld encrypted ODF files of change tracking is heel goed een onderdeel waar je kan kiezen om dat (voorlopig) niet te implementeren. Zeker in een eerste aanzet niet.
Elementaire tekst elementen in de documentstandaard moeten natuurlijk wel ondersteund worden en ook mag daar wel een behoorlijk niveau van ondersteuning verwacht worden.
Met name daar let kijk ik in MS Office SP2 naar omdat dat het meest relevant is om te kijken of het geschikt is voor gebruik met ODF files. Als je bijvoorbeeld klanten/afnemers ook toestaat ODF documenten op te sturen dan moet je wel behoorlijk zeker weten dat ze niet door Office worden vermangeld.
Dan zou er wel zo'n test moeten wezen natuurlijk ...
Dat is een valide argument. Ik baseer mij op een PDF document waarin de ODF Alliance directeur melding maakt van de bevinding. Hoe je het moet reproduceren wordt daarin niet uitgelegd. Jij vroeg je herhaaldelijk af waar die bewering vandaan kwam en dat heb ik je gegeven.
... en de kans is vrij groot dat ik dat bestaan van dergelijke testresultaten een stuk eerder zou weten dan iemand anders hier.
Een vriendelijke waarschuwing. Grootheidswaan is geen plus op je CV.
Als je een door Webwereld (deze week nog) gelinkte pdf al niet kan vinden, hoe groot is dan de kans dat je ook hier en daar een test mist?
Ik ken die PDF natuurlijk wel. Een persbericht waarin de ODF alliance zogenaamd zijn eigen directeur interviewt. Heel apart maar het zijn opvallend afwijkende claims in het persbericht tbv het tegelijk gereleasede factsheet waarin essentieel niks nieuws stond.
Natuurlijk, daarom vroeg je ook of ik wel zeker wist of die man directeur was. Daarom vroeg je je herhaaldelijk af waar de claim vandaan kwam. Heel geloofwaardig Albert. Jij kende de pdf al. :D
Ik denk eerder dat mijn reactie sloeg op het concept idee dat een directeur testjes gaat uitvoeren zxoals jij in je reactie stelde.
Ik kan dat niet serieus denken
De directeur publiceert de bevinding, ik heb niet beweert dat hij het zelf getest had. Maar toegegeven, leuke hAl draai.
Dit noem ik een Peter draai
Je zie toch echt
Het is een bevinding van Marino Marcich, directeur van de ODF Alliance.
en nu ineens
De directeur publiceert de bevinding
Dat is toch echt wel ff iets anders geworden hoor.
Als ik een bevinding binnen krijg via een testcoordinator dan refereer ik naar de testbevinding van die testcoordinator, ook al kan ik op mijn klompen aanvoelen dat die manager het zelf niet getest heeft.
Misschien dat ze dat bij Microsoft anders doen, maar zo doe ik het.
Ander voorbeeld... Zo worden de beslissingen van de Europese Mededingingsautoriteit regelmatig toegedicht aan Mevrouw Kroes. Neem je die ook letterlijk?
Toen voormalig president Bush riep: "We got him." Dacht je toen ook dat hij zelf Sadam uit die put in de woestijn had getrokken?
Maar ik snap dat je door je argumenten heen bent en dat je op dit soort puntjes begint te ziften.
@Dosprompt: Sorry, nu helder is dat je het om het trollen te doen is, is bij mij de interesse wel weg.
Wanneer is er een soort dosprompt/Albert filter hier op webwereld?
Of bepaalde user niet weergeven als je ingelogd bent.
<offtopic>
Peter,
Wie loopt er nu dan te trollen?
Dacht dat jij een tegenstander was van nietszeggende one- en in dit geval een two-liner?
Sorry, dit soort opmerkingen behoren toch echt tot de door jou genoemde troll categorie.
Opmerking met als enige doel een reactie uit te lokken.
Maar ja, ik kan het verkeerd zien </offtopic>
Als je Firefox gebruikt kan je de Greasemonkey plugin gebruiken en daaraan van userscripts.org (zoeken op webwereld) het zeer handige script van Peter Koopman "Better webwereld" toevoegen ... Echt geweldig handig.
Bij deze Peter: Fantastisch en enorm bedankt voor deze uitbreiding ...
Geweldige "Albert-shut-the-F*ck-up" toepassing ;-P
men nemen Firefox browser. Dan installeer je Greasemonkey (jawel werkt ook op minefield win x64)
En vervolgens dit geweldige script voor Greasemonkey.
Thanx Peter ;-)
Door puur alleen de goedgekeurde standaard te gebruiken lijkt MS wel een klein kind. Het volgt de letter en niet de spirit.
OOo werkt zoals het altijd al heeft gewerkt. Door de nieuwe versie te publiceren is het al een de-facto standaard geworden.
Maar dit is de politiek die MS altijd al heeft gevolgd en nu op Office toepast. Zo'n beetje nog de enige moneymachine voor MS. Er zijn namelijk genoeg mensen die niet verder nadenken en alleen maar constateren "dat het nog steeds niet werkt, dus zal het wel aan OOo liggen. Want OOo is een stelletje hobbyisten en MS een groot bedrijf."
Dat is namelijk de gospel die MS en andere closed source bedrijven verspreiden.
Is die hele plug-in nu wel zo belangrijk sinds er steeds meer consumenten en kleine bedrijven er achter komen dat voor de zelfde functionaliteit als msoffice een gratis alternatief in de vorm van openoffice is. En het werkt prima op XP, Vista en dadelijk ook op windows 7. Dus hopla weg illegale kopie van msoffice en legale download open office.
Dan komt de overheid vanzelf wel!
Helemaal mee eens. Zo ben ik ook aan openoffice gekomen. gewoon proberen en zie daar ms office werd overbodig. en op linux draait het ook super. Wij zijn al een paar jaar geleden in ons bedrijf met 106 werknemers overgestapt op ooo. en het werkt prima.
En wat doe je dan als je van een collega een spreatsheet gemaakt in Excel krijgt aangeleverd. Uiteraard met het verzoek om even wat aanpassingen te maken?
Kun je in openoffice ook in MSO gemaakte ppt bestanden openen en bewerken en bijvoorbeeld weer even terug sturen naar je collega?
Kun je ook track changes volledig tussen OpenOffice en MSO uitwisselen?
Zolang dit soort problemen niet getackeld zijn, zal, denk ik, OpenOffice geen ingang vinden in de bedrijfswereld.
En wat doe je dan als je van een collega een spreatsheet gemaakt in Excel krijgt aangeleverd. Uiteraard met het verzoek om even wat aanpassingen te maken?
De ICT afdeling eens na laten kijken, het lijkt mij een beetje vreemd dat bestanden die nog door anderen aangepast moeten worden door verschillende Office programma's heen moeten.
Als de bestanden buiten het eigen bedrijf door derden aangepast dienen te worden moet je jezelf op de hoogte stellen waar deze mee werkt en er rekening mee houden, dit is al vanaf het begin van het computer tijdperk zo, niet alleen in merk en soort, maar ook versie verschillen.
Wij zijn al een paar jaar geleden in ons bedrijf met 106 werknemers overgestapt op ooo.
En wat doe je dan als je van een collega een spreatsheet gemaakt in Excel krijgt aangeleverd.
Hoe groot is die kans als het hele bedrijf is overgestapt op OOo? In dit geval zou ik dan zeggen: Terug sturen en vragen of hij het in het juiste formaat wil aanleveren.
En wat doe je dan als je van een collega een spreatsheet gemaakt in Excel krijgt aangeleverd. Uiteraard met het verzoek om even wat aanpassingen te maken?
Gewoon terugsturen. Waar het omgaat is wat je afspreek. Ongevraagde legacy formaten dus routeren naar /dev/null
Dat maakt nog steeds niet uit.
Change tracking is gewoon niet volledig in orde in OOo dus het is niet zinvol om een document uit te wiseelen om wat aanpassingen te maken en te verwachten dat changes volledig getracked worden.
Binnen 1 en hetzelfde bedrijf kun je misschien kiezen voor SVN als alternatief voor changetracking in het document.
Binnen 1 en hetzelfde bedrijf kun je misschien kiezen voor SVN als alternatief voor changetracking in het document.
Binnen één en hetzelfde bedrijf zorg je dat iedereen op dezelfde versie zit, dit streef je voor elk soort pakket na, niet alleen voor je Office Suite (van welk merk dan ook).
Het is gewoon te hopen dat de Open Formaten zo snel mogelijk een hoog niveau van kwaliteit halen en de bijhorende pakketten downwards compatible blijven.
Dit gaat niet lukken als de partijen niet samenwerken, dit samenwerken gaat dus schijnbaar niet lukken doordat de partijen hier verschillende belangen in hebben.
Binnen XML-documenten is gewaarborgd changetracking kinderspel.Ik zie eigenlijk geen reden waarom applicaties van deze feature afzien.
Kinderspel is misschien wat te gemakkelijk.
ODF ondersteunt geen volledige changetracking. ODF beperkt zich tot change tracking van tekst elementen maar bijvorbeeld niet in embedded elementen zoals tabellen of math elementen zoals dat in OOXML wel kan.
Bovendien is de changetracking via het ODF formaat heel anders dan van bijvoorbeeld OOXML qua architectuur.
OOXML houdt changes bij op de plaats waar ze plaatsvinden. ODF heeft een apart document gedeelte waarin alle changes staan changes en linkt die via een referentie aan de plek in het document waar ze plaatsvinden.
Dat is qua implementatie een enorm verschil en het is niet makkelijk om een derglijk systeem intern te converteren.
Dat soort dingen deed ik in de vorige eeuw. Nu zijn mijn programmeer kwaliteiten daar zeker niet meer voldoende voor (als ze dat ooit al waren).
Bovendien wordt OpenOffice gewoon ontwikkeld door proffesionele programmeurs betaald door Sun, Novell en IBM.
Vertalen van OSS GUI's heb ik nog tot een jaar of 6 geleden gedaan maar eigenlijk maar ik maak gewoon te veel spellingsvauten en zie dat anderen er gewoon beter in zijn.
Het is wel een goede intro voor mensen die zich met oss willen bemoeien maar voor wie source code eigenlijk niet een optie is. En er zijn altijd projecten die vertalers nodig hebben hoewel ik moet zeggen dat Nederlanders daarin al actiever zijn dan de meesten. Kies dan wel iets wat dicht bij je interesse ligt dan werkt het vertalen van zaken vaak ook beter.
Heb je als consument zelf een msoffice pakket gekocht. En deze niet op meerdere computers gezet.
Dus helemaal legaal bezig. (serieuze vraag zonder bijbedoelingen)
Van office 2007 heb zelf een zelf gekocht pakket, een van een werkgever, een werkende gratis beta en nog een ander...
Van alles wat zeg maar.
MS Office voor thuisgebruik kost je tegenwoordig 75 euro voor drie computers.
Dat is goed te doen denk ik.
De andere versies vind ik voor thuisgebruikers vrij duur.
MS Office voor thuisgebruik kost je tegenwoordig 75 euro voor drie computers.
Dat is goed te doen denk ik.
Voor jouw misschien. Ik gebruik liever OpenOffice, kost 0 euro en mag op oneindig veel computers geïnstalleerd worden. Die 75 euro gebruik ik wel voor nuttiger zaken.
MS Office zal niet gratis worden.
Ik denk dat er wel bijvoorbeeld abbo varianten zullen ontstaan waarbij je betaalt per maand en dan ook kan kiezen tussen een on line suite en een geinstalleerde versie.
Ik denk dat OpenOffice op de langere termijn (bijna) zal verdwijnen omdat de bedrijven achter OOo ook liever zullen kiezen voor een volledig on line variant met abbo wat een betere business case is voor een software producent.
Ik denk ook niet dat MSO gratis zal worden. De prijs zal verder dalen en het gebruik ook. De tendens is op dit moment dat OOo steeds verder groeit. Nederland loopt zoals altijd achter op dat gebied. Denk een paar jaar geleden aan Wordperfect. Nederland liep ook daar ver achter. Iedereen zat al op MSO behalve Nederland. Hier bleef men met WP werken. Ons bedrijf dus ook. 4 jaar geleden werd pas de overstap naar OOo gemaakt. Ik denk dat concurreren met iets wat gratis is behoorlijk moeilijk is. De kwaliteit groeit met elke versie die uit komt dus de voorsprong die MSO heeft slinkt met elke versie. Het online aanbieden van applicaties zie ik ook niet zo 1 2 3 doorzetten. Is mijn inziens een van de vele hypes die we hebben zien voorbij komen en die dan toch niet doorzetten.
De Franse belasting bespaart tien miljoen per jaar door voor OpenOffice te kiezen.
Het kan zelfs nog "erger":
A recent report has revealed that France's national police force has saved an estimated 50 million euros since 2004 by adopting open source software and migrating a portion of the organization's workstations to Ubuntu Linux. They plan to roll out the Linux distro to all 90,000 of their workstations by 2015.
French police adopts Ubuntu
French gendarmerie saves millions
Microsoft staat in het goed recht versie 1.1 te implementeren.
Immers is een draft nog geen standaard, maar, zoals het woord het ook zegt, een draft.
Kijk bijvoorbeeld eens naar 802.11n. Hoeveel gedonder is daar niet mee geweest? Dat was ook een draft, en drafts kunnen gewijzigd worden.
Kortom, als microsoft een draft versie van ODF1.2 zou implementeren en er zou nog een aanpassing op komen, dan zijn documenten opgeslagen in de draft versie opeens niet compatible meer.
En als dat gebeurt dan is de wereld ook weer te klein.
't is eigenlijk nooit goed.
Het probleem is mijns inziens juist dat Microsoft bewust te snel is begonnen met ondersteuning van ODF. Een bewuste keuze omdat ze weten dat een perfecte ondersteuning op basis van de ISO standaard nog niet mogelijk is.
Delen van de ODF ondersteuning leunen nu nog op onderling overleg. Microsoft heeft besloten overleg te negeren en alleen de standaard naar de letter te implementeren. Alles wat niet duidelijk is hebben ze een eigen invulling aan gegeven en delen die volgen hen niet goed genoeg waren hebben ze maar helemaal niet geïmplementeerd.
En aangezien de code van Microsoft gesloten is kan niemand anders dan Microsoft het probleem oplossen. Ik vermoed alleen dat ze na de eerste krachtsinspanning niet zoveel haast meer gaan hebben.
Veel gepraat hier over welke versie van ODF Microsoft zou hebben moeten implementeren. In mijn opinie is de keuze voor versie 1.1 de juiste basis. Dat ze de versie 1.1 niet perfect hebben geïmplementeerd, ach, foutjes worden gemaakt. De fouten zijn niet nog niet erg schokkend. Een aantal foutjes zouden ze al met de eerst volgende patch ronde kunnen aanpakken, zoals het vergeten van de "[" en de "]" alsmede de formule bij het opslaan. De feature "Track Changes" kan men daarna dan aanpakken. Encryptie inbakken zal wel wat meer kosten qua tijd.
Al met al een redelijk geslaagde eerste poging van Microsoft. Drie patch-rondes later zal men zeker volledig ODF 1.1 moeten kunnen ondersteunen.
PS
Voor de pessimisten e.d. onder ons, het had vele male erger gekund.
Een aantal foutjes zouden ze al met de eerst volgende patch ronde kunnen aanpakken
Voor de pessimisten e.d. onder ons, het had vele male erger gekund.
Ik ben zo'n pessimist die verwacht dat de eerst volgende patchronde wel eens heel lang op zich kan gaan laten wachten.
Het past tenminste perfect in het plaatje dat nu ontstaat.
Ik ben zo'n pessimist die verwacht dat de eerst volgende patchronde wel eens heel lang op zich kan gaan laten wachten.
Jij, pessimist? Had ik niet verwacht. ;-)
Over het algemeen valt het wel mee, maar voor deze actie van Microsoft maak ik graag een uitzondering.
Toen ze aankondigden dat ze ODF zouden ondersteunen had ik goede hoop dat ze eindelijk een draai richting interoperabiliteit zouden gaan maken. Helaas hebben een paar recente acties dit intussen weer getorpedeerd.
Ik denk dat we gewoon moeten accepteren dat interoperabiliteit door Microsoft gezien wordt als een risico, dus dat we op dat gebied niet teveel mogen verwachten van de heren uit Redmond.
Jammer, maar helaas niets anders aan te doen dan stemmen met de voetjes.
Dat ze de versie 1.1 niet perfect hebben geïmplementeerd, ach, foutjes worden gemaakt. De fouten zijn niet nog niet erg schokkend. Een aantal foutjes zouden ze al met de eerst volgende patch ronde kunnen aanpakken, zoals het vergeten van de "[" en de "]" alsmede de formule bij het opslaan.
Voorlopig zie ik geen foutjes die ze gaan aanpakken. Zover ik kan zien zijn het geen foutjes maar allen bewuste keuzen. De celreferenties zonder blokhaken en de formules zijn zo toegepast als in de formulataal uit ISO/IEC 29500 en zullen ze zeker niet gaan aanpassen tot ODF 1.2 met OpenFormula een ISO standaard is geworden.
De encryptie en changetracking zullen ze mogelijk gaan inbouwen als hun klanten daar behoefte aan hebben.
Het gaat om vaste patroon bij Microsoft.
Zij richten zich op hun afnemers en met name organisaties en wat die willen en nodig hebben.
Ze hebben in hun interoperability workshop 9 maanden geleden al hun principes vastgelegd waardoor hun keuzes voor MS Office SP2 bepaald zijn.
http://orcmid.com/blog/2008/08/microsoft-odf-interoperability-workshop.asp#a2`
Een voorbeeld van die principes is "be predictable". Ze gaan dus niet een beetje sleutelen aan hun formuletaal zoals Jachra, waar ik op reageerde, nog dacht.
Als er fouten in hun implementatie zitten zullen ze die vermoedelijk wel aanpassen maar de zaken in het onderwerp betreffen keuzes die ze opzettelijk gemaakt hebben en die hun vastgelegde principes voor ODF interoperabiliteit symboliseren en daar zullen ze niet zomaar aankomen.
Een voorbeeld van die principes is "be predictable".
<sarcasme>
Ja, als je een spreadsheet opent en vervolgens weer opslaat worden bijvoorbeeld alle formule's uit die spreadsheet gewist. Natuurlijk had Microsoft ook gewoon de formule's kunnen laten staan maar Microsoft klanten verwachten dat nu eenmaal niet. Klanten van Microsoft gaan er vanuit dat als je een spreadsheet opslaat dat je dan de formule's kwijt bent en daarom heeft Microsoft, in overeenstemming met hun principe altijd 'predictable' te zijn, het op deze manier geïmplementeerd.
</sarcasme>
Bijvoorbeeld IBM's Symphony (OOo kloon) laat de formules die het niet herkent staan maar daardoor breekt vaak de complete functionaliteit van het spreadsheet.
Het gaat in een spreadsheet dat je aan een andere partij verstuurt vaker om het resultaat dan om het laten manipuleren van de spreadsheet. MS Office preserveert het resultaat. De getallen in het spreadsheet zijn gelijk aan zoals de verzender die heeft verstuurt. Je kunt het resultaat niet manipuleren omdat de onderliggende formules weg zijn maar de boodschap van de verzender is nog intact.
Symphony behoudt wel onbekende onderliggende formules en laat niet de data zien maar de onbekende formule. Het resultaat van de berekening is dan niet meer zichtbaar in de spreadsheet en de spreadhseet is voor de ontvanger onbruikbaar tenzij deze zelf eerst handmatige alle onbekende formules gaat corrigeren naar bekende formules (als de ontvanger dat al kan).
Dat is de oplossing van MS ver te prefereren
Ach ja, data verliezen is ver te prefereren boven het moeten corrigeren van data. Het zal de Microsoft logica wel zijn.
De essentie is juist dat in de keuze van MS de data behouden blijft. De spreadsheet ziet er in Excel het zelfde uit als de originele implementatie. In bijvoorbeeld Symphony zien OOo 3.x spreadsheets er gewoon verminkt uit.
Als je bijvoorbeeld electronische facturen stuurt gemaakt in ODF spreadsheets dan wil je wel dat de ontvanger ze kan lezen en niet dat ze verminkte documenten zien.
Als een document verminkt is doordat de inlezende applicatie de formules niet kan inlezen dan is de informatie juist niet beschikbaar.
Als je zoals Excel het document volledig zo toont als de verzender dat verstuurt heeft is wel alle data beschikbaar. Je kunt alleen de data niet meer manipuleren.
Ik gaf al het voorbeeld van in ODF aangemaakte facturen.
Het is volstrekt niet acceptabel als een inlezende applicaties dergelijke documenten verminkt zoals momenteel IBM's Symphony de files uit OOo verminkt. In Excel zie dat soort documenten er nog correct uit.
In Excel zie dat soort documenten er nog correct uit.
Je zegt het goed. Het is niet goed, het ziet er alleen goed uit. Uiterlijkheden worden gesteld boven functionaliteit.
Je zegt het goed. Het is niet goed
Het is wel goed.
Je bent wel functionaliteit uit het spreadsheet kwijt maar het spreadsheet is prima in orde en de informatie erin klopt ook gewoon. Als een applicatie de formules niet herkent dan is de hele berekening uit het sheet verloren en dan zijn de gegeven niet mee betrouwbaar (als ze uberhaupt nog getoond kunnen worden)
Dat is de meest elegante oplossing.
Dat hangt helemaal af van het doel. Ik zie regelmatig sheets voorbij komen die nog bewerkt moeten worden, dan heeft de MS-oplossing geen zin. Maar ik zie ook sheets voorbij komen waarbij alleen de berekende waarden van belang zijn. Dan is juist de MS oplossing de meest zinnige.
Als ze het netjes deden zouden ze de waarde samen met de formule in een cel moeten weergeven (bv tussen []).
Als het verminkt wordt in Excel maar niet in OOo, dan moet je OOo gebruiken, dat is ook nog eens een keer gratis.
Niet een logische opmerking want het is juist OOo die namespaced formules aangemaakt door Excel niet herkent en daardoor ODF spreadsheet deels visueel verminkt.
Je moet dus juist niet OOo nemen om Excel ODF spreadsheet in te lezen. Je kunt beter dan beter de nieuwe KOffice nemen want die kan zowel OOo als Excel spreadshhet inlezen (helaas heeft die suite andere meer functionele beperkingen)
Ik moet mensen afraden omExcel te gebruiken om ODF 1.1 documenten te lezen. De kans dat ze vernield worden is aanwezig.
Andersom moet je juist afraden.
Je moet geen OOo gebruiken om Excel spreadsheets in te lezen. De van een aparte namespace voorziene ISO/IEC 29500 formules werken dan in OOo niet en als je er in gaat editten krijgen je mogelijk een set van wel en niet werkende spreadsheet formules en is het volstrekt onvoorspelbaar wat de uitkomst is van het spreadsheet.
De essentie is juist dat in de keuze van MS de data behouden blijft.
Het wissen van formule's presenteren als het behouden van data. Dat is zelfs voor jouw doen zeldzaam krankzinnig.
Dat is een vreemde bewering. Formules maken geen onderdeel uit van de informatie maar dienen voor het berekenen van de informatie.
Inderdaad nogal flauw. :)
Meer zoals de motor een onderdeel is van een auto. Zonder motor ziet het er nog uit als een auto, maar toch mist er iets essentieels. Als er onderdelen van de motor niet passen, dan heb ik toch liever dat ik dat zie. Ook al werkt de auto dan niet en staan die lelijke losse onderdelen die los op de motorkap liggen lelijk. Ik kan dan in elk geval onderdelen, die wel passen, gaan bestellen. Het staat zo lullig als je er na een week bij de eerste start achter komt dat je een leeg stuk blik hebt ipv een auto.
Als je ontkent dat een formule onderdeel is van de data, dan heb je gelijk. Het risico van deze methode is, dat het rekenblad er op het oog correct uit ziet. Dat je bij opslaan informatie verliest kan er dus gemakkelijk insluipen.
Maar zoals ik al zei, het zal Microsoft logica zijn. Dataverlies accepteren ter wille van de gebruikerservaring lijkt te horen bij een voorspelbaar Microsoft.
Maar zoals ik al zei, het zal Microsoft logica zijn. Dataverlies accepteren ter wille van de gebruikerservaring lijkt te horen bij een voorspelbaar Microsoft.
Stel je voor dat je een flink poosje met een bepaalde spreadsheet aan het werk bent geweest. Vervolgens vraag je je secretaresse nog even een paar kleine dingetjes aan te passen. Die doet natuurlijk met Excel, want dat is het enigste wat ze heeft gehad op school. Vervolgens ben je je werk kwijt. Dit heeft niets te maken met het behouden van data, maar alles met het duperen van je klanten.
Geef dan een _duidelijke_ melding dat je de formule's niet herkent en geef de klant de _optie_ om de formule's te overschrijven met de laatste getalswaarde.
Als software makers een prioriteit zouden moeten hebben dan zou dat wel het voorkomen van dataverlies bij hun klanten moeten zijn. Het rechtstreeks _veroorzaken_ van dataverlies is van een andere planeet.
<extreem sarcasme>
Als je in de volgende versie van MS-Office een ODF bestand opent dan slaat MS-Office een screenshot hiervan op en wist het originele bestand. Dat is om de 'data te behouden'.
</extreem sarcasme>
Stel je voor dat je een flink poosje met een bepaalde spreadsheet aan het werk bent geweest. Vervolgens vraag je je secretaresse nog even een paar kleine dingetjes aan te passen. Die doet natuurlijk met Excel, want dat is het enigste wat ze heeft gehad op school. Vervolgens ben je je werk kwijt. Dit heeft niets te maken met het behouden van data, maar alles met het duperen van je klanten.
Allereest vind ik het een belachelijk suggestie omdat je binnen een bedrijf gewoon een consistente spreadsheet implementatie moet gebruiken.
Verder stel ik me het andere kant voor dat jij naar je secretaresse een ODF spreadsheet zou sturen en dat er dan in plaats van waardes de formules verminkt in haar scherm staan en het spreadsheet volstrekt onbruikbaar is zoals nu IBM's Symphony met OOo en Excel spreadsheet doet.
Het is dan sowieso gewoon helemaal geen optie meer om spreadsheets uit te wisselen tussen implementatie met verschilledne formules.
Allereest vind ik het een belachelijk suggestie omdat je binnen een bedrijf gewoon een consistente spreadsheet implementatie moet gebruiken.
Microsoft speelt Russische roulette met de data van haar klanten. Waarschijnlijk kun jij wel een aantal voorbeelden verzinnen (5 bijvoorbeeld) waar het spelen van Russische roulette geen problemen geeft. Dat wil niet zeggen dat het spelen van Russische roulette nooit problemen geeft. Dat is een onheuse generalisatie.
We hebben het hier over het wissen van data door Microsoft Excel. Jij komt met een voorbeeld waar de gewiste data toevallig niet belangrijk is, dat wil niet zeggen dat de door Excel gewiste data nooit belangrijk zou zijn.
Ik geef _een_ voorbeeld waar de gewiste data toevallig wel belangrijk is. Jij doet dat voorbeeld af als 'belachelijk' omdat je binnen een bedrijf 'gewoon een consistente spreadsheet implementatie moet gebruiken'. Ik denk dat iedereen die dit leest voor zichzelf de merites van deze 'weerlegging' kan bepalen.
Verder stel ik me het andere kant voor dat jij naar je secretaresse een ODF spreadsheet zou sturen en dat er dan in plaats van waardes de formules verminkt in haar scherm staan en het spreadsheet volstrekt onbruikbaar is zoals nu IBM's Symphony met OOo en Excel spreadsheet doet.
Dat hangt er dus vanaf of die formules wel of niet belangrijk zijn. Er zijn situaties te bedenken waar het verlies van die formules niet erg zal zijn, maar er zijn ook situaties denkbaar waar het verlies van die formules ernstige gevolgen kan hebben. Over het algemeen is het niet verstandig om de defaulten naar onherstelbaar dataverlies. Misschien is het een goed idee als klanten van Microsoft zelf kunnen bepalen wanneer hun data veilig gewist kan worden?
Een ander punt is dat het weergeven van de laatste numerieke waarde van een cel op het moment dat je de formule in die cel niet begrijpt automatisch gepaard moet gaan met het daadwerkelijk wissen van die formule. Je kunt makkelijk de laatste getalwaarde gebruiken als zichtbare representatie van een cel zonder dat je daarvoor perse de formule inhoud van een cel hoeft te wissen. Op het moment dat een gebruiker deze cel dan wil aanpassen kun je een _melding_ geven dat Excel de onderliggende formule niet begrijpt en de klant daarop de _keuze_ geven de formules uit de spreadsheet te wissen.
Het is niet MS die risico's neemt met data van haar klanten maar de wel bijvoorbeeld alle OOo en varianten (zoals IBM Symphony) waarvan de verschillende versies spreadhseet verminkt tonen zodat ze voor documenten van buiten de organosatie volstrekt niet bruikbaar zijn. Zelfs de meest basic OOo spreadsheet kan door Symphony gebruikers al niet goed worden gelezen.
Te triest voor woorden voor 2 spreadsheetversies vanuit dezelfde codebase.
Bovendien nog partners in OOo ontwikkeling
Schandalig is eigenlijk meer het juiste woord.
De MS oplossing behoudt de dat zodat als je en documetn krijgt tyoegestuurd dat het er gewoon hetzelfde uitziet als dat je verzneder dat bedoeld had.
Dat OOo varianten dat onderling niet eens kunnen is gewoon belachelijk en schandalig.
Een ander punt is dat het weergeven van de laatste numerieke waarde van een cel op het moment dat je de formule in die cel niet begrijpt automatisch gepaard moet gaan met het daadwerkelijk wissen van die formule. Je kunt makkelijk de laatste getalwaarde gebruiken als zichtbare representatie van een cel zonder dat je daarvoor perse de formule inhoud van een cel hoeft te wissen
Elke willekeurige mutatie van de spreadsheet leidt tot het zinloos maken van de formules in een spreadsheet als de applicatie niet 100% van alle formules kan doorrekenen. Het is dus volstrekt logisch om alleen de data te laten zien en de formules te verwijderen. Het laten staan van door de applicatie niet begrepen formules heeft geen enkel zinnig nut.
Stel je voor dat je een flink poosje met een bepaalde spreadsheet aan het werk bent geweest.
En stel je voor dat je die sheet gaat tonen aan de directie. En stel je voor dat, zoals hier geopperd wordt, niet de data maar de formules getoond worden.
Nogmaals, als ik het goed begrijp is er in ODF1.1 niets vastgelegd over formules. Een eigen interpretatie daaraan geven (wat de andere offices doen) mag dus niet, want dat is juist wat MS nogal eens verweten wordt.
Je hebt dan dus twee keuzes:
Je laat de celinhoud intact en toont dus de formule. Daar zullen je jaarcijfers niet duidelijker mee worden.
Of je toont de waarde. Daar is de directie blij mee, alleen kun je de sheet niet meer aanpassen.
Zo bezien is ODF1.1 nutteloos voor spreadsheets.
Dat is een vreemde bewering. Formules maken geen onderdeel uit van de informatie maar dienen voor het berekenen van de informatie.
Natuurlijk vertegenwoordigen de formules wel informatie.
En stel je voor dat je die sheet gaat tonen aan de directie. En stel je voor dat, zoals hier geopperd wordt, niet de data maar de formules getoond worden.
Ten eerste hoef je niet noodzakelijkerwijs de formules te deleten om de laatste getalswaarde weer te geven. Ten tweede weet je als office suite niet of die spreadsheet is bedoeld om aan de directie te laten zien, of dat de formules toevallig erg belangrijk zijn. Wat is dan logisch, voor de zekerheid de formules dan maar wel deleten? Of zou het misschien beter zijn de formules voor de zekerheid maar niet te deleten?
Ten eerste hoef je niet noodzakelijkerwijs de formules te deleten om de laatste getalswaarde weer te geven.
Als je de formules niet herkent dan moet je ze verwijderen.
Als je dat niet doet loop je extreem veel risico op fatale informatiefouten waneer iemand data in het spreadsheet gaat muteren.
Je hebt dan geen idee welke berekeningen er wel of niet uitgevoerd worden. Echt een krankzinnig idee om dan nog formules in tact te laten. Volstrekt belachelijk
Echt een krankzinnig idee om dan nog formules in tact te laten. Volstrekt belachelijk
Waarmee je weer eens je minachting toont voor elke mening die afwijkt van de jouwe. In een draad die nu al meer dan een week oud is.
Predictable.
Laat het gaan, knul. Laat het gaan.
Sorry hoor maar ik reageer op een bericht van een half uur eerder omdat die reactie van alon op de frontpagina als laatste reactie werd getoond. Typisch dat je die reactie niet op alon geeft die na een paar dagen nog hier gaat rondstruinen en thread gaatr opvolgen (of jijzelf bijvoorbeeld).
Verder voeg je inhoudelijk niks aan de discussie toe maar plaatst alleen amar en persoonlijke aanval.
belachelijk
Niet inhoudelijk.
krankzinnig
Niet inhoudelijk.
Moedwillige informatievernietiging is bij mijn werkgever reden voor ontslag. Hoe denkt jouw werkgever daar over? Dat je moedwillige informatievernietiging verdedigt kan ik alleen verklaren uit je zendingsdrift voor Microsoft.
Deze draad is nu tien dagen oud. Je MS-zendingsdrift gaat gepaard met een sterke drang om het laatste woord te hebben.
Zoek hulp.
Moedwillige informatievernietiging is bij mijn werkgever reden voor ontslag. Hoe denkt jouw werkgever daar over?
Wat een dom geblaat zeg.
Je negeert gewoon alles wat ik zeg en komt dan met zo'n flutkreet.
Inhoud nul, kretelogie 100
Als je de spreadhseet niet wilt manipuleren is er sowieso niets aan de hand. De binnengekregen spreadsheet kun je dan bewaren (dat kun je natuurlijk altijd gewoon doen) en Excel laat die precies zo zien als de verzendende partij dat wilde.
Als je een spreadsheet met door de verwerkende applicatie niet herkende formulest wel wilde manipuleren dan kan dat in Excel niet meer omdat de niet herkende formules verwijderd zijn maar kan dat in andere spreadsheet nog wel waar dan de niet herkende formules niet worden doorgerekend zodat het gemanipuleerde spreadsheet meteen corrupt is.
Ik vind een keuze waarbij de spreadsheet zo getoond wordt aan de gebruikers zoals de verzender die bedoeld heeft een goed oplossing en beter dan een oplossing die leidt tot potentiele corruptie van de spreadsheet door willekeurige mutaties op die spreadsheet.
Een optimalere oplossing zou zijn om natuurlijk de spreadsheet formules te standaardiseren zodat ze altijd kunne worden herkend en geinterpreteerd maar dat is dus nog voor de toekomst.
Ik vind een keuze waarbij de spreadsheet zo getoond wordt aan de gebruikers zoals de verzender die bedoeld heeft een goed oplossing
Ik begrijp dat de makers van MS-Office een plugin voor gedachtenlezen hebben ontwikkeld. Dat is een hele prestatie.
dom geblaat
Welsprekendheid is niet één van jouw talenten, knul.
Het is mogelijk om van tevoren een ongeschonden kopie van je spreadsheet veilig te stellen, voordat je 'm door de MS-mangel haalt. Het is het soort suggestie waardoor ik wel eens twijfel of je werkelijk in de IT werkt.
Je blijft hardnekkeig inhoudelijk negeren dat je in een spreadsheet met niet werkende formules de data in een spreadhseet niet kan manipuleren zonder onoverzichtelijk risico's op corruptie van de spreadsheet doordat de niet herkende formules niet of niet correct worden bijgewerkt.
Als je bijvoorbeeld in excel iets simpels doet als een rij of kolom toevoegen dan worden gerelateerde formules doorde spreadsheet aangepast. Formules die niet als zodanig herkend worden kunnen niet worden aangepast ergo corruptie.
Het voorstelling van oplossingen die dat in de hand werken is gewoon bespottelijk net als het negeren van dat overduidelijke duidelijke probleem in het zogenaamde nut van het behouden van de formules.
En liever een gesprek aan welsprekendheid dan een blijkbaar gebrek om inhoudelijk te begrijpen waar het over gaat.
Je blijft hardnekkeig inhoudelijk negeren dat je in een spreadsheet met niet werkende formules de data in een spreadhseet niet kan manipuleren
Niet met MS-Office, nee. Dus moet je met MS-Office van ODF-spreadsheets uit OOo, koffice etc. afblijven als je informatie niet wilt vernietigen.
De OSS-officesuites hebben ooit met veel moeite geleerd de MS-formaten via reverse engineering te hanteren. MS kiest er daarentegen voor om niet aan te sluiten op een bestaande praktijk, niet omdat het te moeilijk voor ze is - de OSS-code is vrij toegankelijk - maar omdat ze dat niet uitkomt. En passant zorgt MS-Office ook nog eens voor informatieverlies. Jij vindt dat OK. Soit. Ik zou je niet graag als collega hebben met zo'n houding.
Ik herhaal nog maar eens dat mijn werkgever, mijn vorige werkgever, en die daarvoor ook, moedwillige informatievernietiging met ontslag belonen. Wat vindt jouw werkgever er van?
Wat je stijl van argumenteren betreft: obsessief, laag bij de gronds.
Zoek hulp.
Niet met MS-Office, nee. Dus moet je met MS-Office van ODF-spreadsheets uit OOo, koffice etc. afblijven als je informatie niet wilt vernietigen
Onjuist, MS Office corrumpeert je spreadsheet niet.
Corruptite treddt juist of met IBM's Symphony bijvoorbeeld of met NeoOffice en andere OOo 2.x afgeleiden die niet herkende formules in de spreadsheet laten staan.
Als je daarmee een OOo 3.x ODF spreadsheet opent met nieuwe formuletaal dan worden de formules verminkt getoont en kan de spreadsheet niet doorgerekent worden. Het muteren van gegevens in die spreadsheet en die opslaan is dan dus zinloos. Het principe van bewaren van niet herkende formules bij het muteren van een spreadsheet is gewoon onzin. Als je spreadsheet applicatie de niet herkende formules niet aanpast of doorrekent aan de hand van gemaakte mutaties dan is de spreadheet in essentie corrupt.
Ik beweer nergens dat MS Office spreadsheets corrumpeert. Ik beweer dat MS Office informatie vernietigt.
Ik herhaal mijn vraag: hoe staat jouw werkgever tegenover informatievernitiging?
...omdat de ontwikkelaars van MS Office er voor hebben gekozen dat MS Office die formules niet herkent. Ze hadden een andere beslissing kunnen nemen. Dat hebben ze niet gedaan. En nu vernietigt MS Office informatie.
Ik herhaal: hoe staat jouw werkgever tegenover informatievernietiging? De mijne wordt er heeeel sikkeneurig van.
MS Office heeft gekozen voor een open standaard formule taal ipv een niet gedocumenteerd propriety spreadsheet formaat van een spreadsheet applicatie die inmiddels dat formaat ook heeft afgeschreven. Iedere implementatie kan over 10 jaar nog steeds die spreadheet formule taal interpreteren maar de oude OOo spreadsheet formules zijn nu al aan het uitsterven nu OOo ze zelf heeft gedumped.
Verder vernietigd excel niet de informatie maar doen juist de verschuillende andere implementaties gebaseerd op OOo juist dat.
Als je de formules niet herkent dan moet je ze verwijderen. Als je dat niet doet loop je extreem veel risico op fatale informatiefouten waneer iemand data in het spreadsheet gaat muteren.
Van Dale:
fa·taal bn, bw noodlottig; de dood tot gevolg hebbend
Stel je een arts voor die een ODF 1.2 spreadsheet gebruikt om op basis van een aantal patiënt-afhankelijke parameters de dosering van een zeker medicijn te berekenen. Als de arts deze spreadsheet opent met Symphony ziet hij dat er iets mis is met de formules en kan hij zijn handelingen daarop aanpassen.
Opent hij deze spreadsheet met Excel dan worden de formules ongemerkt gewist en vervangen door de laatste getalswaarden. Op dit moment ziet de spreadsheet er niet anders uit dan anders, de arts hoeft dus niet in de gaten de hebben dat er iets mis is met de formules. Vult hij nu de parameters van een patiënt in dan blijft de resulterende dosering gelijk aan die van de vorige patiënt. Dat lijkt mij een fout die fatale gevolgen kan hebben.
Misschien heeft de arts ook wel enige moeite gestoken in het bepalen van de juiste formules voor de berekening van de dosering. Zelfs als deze 'informatiefout' geen fatale gevolgen heeft dan nog is de arts gedupeerd door het door Excel veroorzaakte dataverlies.
Juist al je een een incompatible spreadsheet in Excel opent krijg je een duidelijke waarschuwing dat de formules in de spreadsheet niet meer werken.
In Symphony krijg je helemaal geen waarschuwing. Die leest de spreadsheet. Als uit je voorbeeld een arts de betreffende spreadsheet inleest zie hij misschien 1 verminkte formule en als hij bijvoorbeeld die formule corrigeert terwijl op achterliggende werkbladen er nog stapels andere formules fout kunnen zijn loop je forse risico's.
Ook apart is dat je hierboven nog usggereerde dat een spreadsheet de verminkte formules niet hoefde te tonen maar de laatsberekende data zou kunnen tonen als de formule maar bewaar bleef.
Dat zou helemaal potentieel rampzalige gevolgen kunnen hebben omdat dan nog onduidelijkerwordt dat de spreadsheet niet meer functioneer al een spreadsheet zou moeten.
belachelijk suggestie ... Te triest voor woorden ... Schandalig ... gewoon belachelijk en schandalig ... Echt een krankzinnig idee ... Volstrekt belachelijk
We hebben het hier om het ongevraagd en onherstelbaar wissen van formules uit ODF documenten door Microsoft Excel. Microsoft kan haar klanten hiermee ernstig duperen.
Jij ziet dat anders. In eerste instantie kom je met de 'argumentatie' dat het wissen van data eigenlijk hetzelfde is als het behouden van data. En omgekeerd, behoud van data staat voor jou gelijk aan dataverlies. Mijn originele karakterisering van deze redenatie lijkt mij volledig terecht.
Vervolgens kom je met de 'argumentatie' dat Excel de formules weliswaar wist, maar dat de formules nu eenmaal nooit belangrijk zijn. Dit 'bewijs' je door een voorbeeld te geven van een situatie waar de formules toevallig inderdaad niet belangrijk zijn. Zoals ik al eerder heb aangegeven is dit een foutieve generalisatie. In het algemeen is het natuurlijk helemaal niet zo dat de formules niet belangrijk zijn. Sterker nog, het kunnen werken met formules is de belangrijkste reden om überhaupt gebruik te maken van een spreadsheet. Met name noem ik ook de mogelijkheid om dezelfde formules te kunnen laten opereren op wisselende data sets.
Natuurlijk zie jij dat ook weer anders. Nu is het blijkbaar volgens jou weliswaar zo dat de formules gewist worden en dat die formules inderdaad belangrijk kunnen zijn, maar dat je als bedrijf 'gewoon een consistente spreadsheet implementatie moet gebruiken'. Het komt er op neer dat er volgens jou dus geen problemen zijn bij het uitwisselen van data omdat je nu eenmaal niet moet proberen om data uit te wisselen. Zoals ik ook al eerder heb aangegeven kan iedereen voor zichzelf bepalen hoe valide dit soort 'argumenten' zijn.
Daar komt natuurlijk nog bij dat dit geen argumenten zijn voor het onherstelbaar en ongevraagd wissen van de formules door Excel in plaats van de gebruiker te waarschuwen dat de formules niet herkend worden en hem/haar de _optie_ te geven de formules te wissen. Er zullen best situaties denkbaar zijn dat het inderdaad het beste is om de formules dan maar te wissen en de cellen te vullen met de laatste getalswaarde. Dat wil niet zeggen dat het verstandig is om dan maar te defaulten naar onherstelbaar dataverlies.
Tot slot gaf ik nog aan dat het niet noodzakelijk is om de formules direct te wissen om een read-only versie van de spreadsheet op basis van de laatste gebruikte numerieke waarden te vertonen. Volgens jou kan dat niet omdat het dan mis gaat als de gebruiker in een later stadium alsnog de spreadsheet gaat proberen te bewerken. Maar dat is ook al een onheuse argumentatie. Ten eerste kan het ook zijn dat de gebruiker de spreadsheet niet nog gaat bewerken, in die situatie heb je dan sowieso dataverlies vermeden. Als de gebruiker de spreadsheet wel nog wil bewerken kun je dan alsnog de formules wissen.
Maar dat is natuurlijk ook niet de kern van het probleem. De kern is dat Excel ongemerkt, automatisch en onherstelbaar de formules uit een spreadsheet wist zonder dat Excel kan beoordelen hoe belangrijk die formules zijn. Alleen de gebruiker kan beoordelen welke gevolgen het wissen van de formules voor hem/haar heeft en hij/zij moet daar dus over ingelicht worden en de mogelijkheid hebben dataverlies te voorkomen.
Dan kun jij met een indrukwekkende hoeveelheid permutaties van 'belachelijk', 'krankzinnig', 'triest' en 'schandalig' aan komen zetten om aan te geven hoe je het zou vinden als Excel gebruikers de mogelijkheid zou geven zelf de bepalen wanneer het handig is zijn/haar data te wissen, mij lijkt dat normaal.
Sterker nog, het kunnen werken met formules is de belangrijkste reden om überhaupt gebruik te maken van een spreadsheet. Met name noem ik ook de mogelijkheid om dezelfde formules te kunnen laten opereren op wisselende data sets
Je negeert de eseentie. Je KUNT NIET met de formules werken omdat de spreadsheet applicatie ze niet herkent. De resultaten van elke willekeurige wijziging in de spreadsheet zijn dus ongewis omdat de spreadsheet geheel of gedeeltelijk niet meer wordt doorgerekend. Het is dan volstrekt zinloos om in de spreadsheet te editten en de formules intact te laten omdat de spreadsheet meteen corrupt zal kunnen zijn en het niet evident meer is voor de gebruiker dat de spreadsheet niet meer goed doorrekent.
...omdat de ontwikkelaars van MS Office er voor hebben gekozen dat MS Office die formules niet herkent. Ze hadden een andere beslissing kunnen nemen. Dat hebben ze niet gedaan. En nu vernietigt MS Office informatie.
Ik herhaal: hoe staat jouw werkgever tegenover informatievernietiging? De mijne wordt er heeeel sikkeneurig van.
Het zou onzin geweest zijn om een obssolete spreadsheet formaat te implementeren wat al door de originele implementatie is verlaten en dat bovendien niet geheel compatibel met Excel is terwijl je al beschikt over een open standaard formaat voor spreadsheet formules dat dor iederen heel makkelijk te herkennen is omdat ze dat ook al in OOXML tegenkomen.
En je beweert telkens dat Excel informatie vernietigd wordt maar dat is toch niet zo. De informatie is in Excel onveranderd.
De informatie wordt juist vvernietigd in OOo derivaten die niet meer aan de gebruiker de data uit de spreadsheet laten zien maar ipv daarvan verminkte formules tonen waar een onvanger niks aan heeft.
Als je een ODF factuur stuurt gemaakt met OOo 3.x dan kun je die in andere OOo 2.x afgeleiden niet meer lezen maar in excel wel.
Het zijn dus juist de OOo derivaten die informatie vernietigen.
En je beweert telkens dat Excel informatie vernietigd wordt maar dat is toch niet zo. De informatie is in Excel onveranderd
De formule is weg. Dat is informatie. Excel verwijdert de formule -> Excel vernietigt informatie.
Een moeilijk leesbare formule is precies dat: niet onleesbaar, maar moeilijk leesbaar. De informatie is er nog steeds. Als de formule om wat voor reden ook niet de keus is van de gebruiker, dan kan de gebruiker alsnog de beslissing nemen om de formule te vervangen door een constante. Dat is aan de gebruiker. MS gaat op de stoel van de gebruiker zitten, besluit dat de formule gepoetst wordt, en vernietigt daarmee informatie.
Ik herhaal: hoe staat jouw werkgever tegenover informatievernietiging? De mijne wordt er chagrijnig van.
Je negeert de eseentie.
Nee ik negeer de essentie helemaal niet. Jij quote een _klein_ gedeelte van mijn vorige reactie, trekt die quote vervolgens uit context, en claimt op basis daarvan dat ik de essentie negeer. Dat is een onheuse manier van discussiëren.
Je KUNT NIET met de formules werken omdat de spreadsheet applicatie ze niet herkent.
Het is niet noodzakelijk om te melden dat je niet met de formules kunt werken omdat Excel ze niet herkent, dat heb ik prima begrepen. Ik claim dan ook nergens in mijn voorgaande reacties ook maar in de verste verte dat Excel wel in staat zou zijn met deze formules te werken. Een beetje een schertsvertoning om dan in hoofdletters te gaan lopen roepen dat Excel dit inderdaad niet kan.
De essentie van de zaak is natuurlijk dat als Excel die formules dan maar gelijk delete dat je dan ook niet meer met de formules kunt werken in een spreadsheet die ze wel had kunnen herkennen. Microsoft heeft voor haar klanten besloten dat als de formules niet met Excel te gebruiken zijn dat haar klanten die formules dan maar helemaal niet meer nodig hebben.
goh, dan heb je inderdaad ook gewoon het originele bestand nog.
Behalve als het toevallig het originele bestand was dat je met Excel opende.
omdat de spreadsheet meteen corrupt zal kunnen zijn en het niet evident meer is voor de gebruiker dat de spreadsheet niet meer goed doorrekent ... En zodra je een spreadsheetbestand met niet geelimineerde maar niet door de spreadsheet applicatie herkende formules gaat bewerken is het potentieel meteen corrupt wat dan niet evident is voor de gebruiker.
Iemand van Microsoft heeft met OpenOffice een ODF spreadsheet gemaakt, deze vervolgens geopend met Excel en Symphony en daar vervolgens screenshots van gemaakt. Laten we die screenshots nu eens aandachtig bekijken:
Symphony - Excel
Symphony en Excel rekenen beide niet goed meer door, maar in welke plaatje is het nu 'evident' dat er iets mis is met de formules?
De essentie van de zaak is natuurlijk dat als Excel die formules dan maar gelijk delete dat je dan ook niet meer met de formules kunt werken in een spreadsheet die ze wel had kunnen herkennen.
Daar kun je toch gewoon het originele bestand voor gebruiken.
Als je echter in een spreadsheet die de formules niet herkent mutaties maakt en wegsaved dan is er meteen corruptie risico als je de formules laat staan.
Daar kun je toch gewoon het originele bestand voor gebruiken.
Behalve als het toevallig het originele bestand was dat je met Excel opende.
Als je echter in een spreadsheet die de formules niet herkent mutaties maakt en wegsaved dan is er meteen corruptie risico als je de formules laat staan.
Ja dat blijf je maar herhalen en herhalen en herhalen. Maar ik denk dat iedereen snapt dat als Excel weigert de formules te herkennen, dat dan de formules niet meer doorgerekend worden. Als de formules helemaal weg zijn worden ze trouwens ook niet meer doorgerekend.
Er zijn situaties te bedenken waar het verlies van die formules niet erg zal zijn, maar er zijn ook situaties denkbaar waar het verlies van die formules ernstige gevolgen kan hebben. Over het algemeen is het niet verstandig om de defaulten naar onherstelbaar dataverlies. Misschien is het een goed idee als klanten van Microsoft zelf kunnen bepalen wanneer hun data veilig gewist kan worden? (klik)
De kern is dat Excel ongemerkt, automatisch en onherstelbaar de formules uit een spreadsheet wist zonder dat Excel kan beoordelen hoe belangrijk die formules zijn. Alleen de gebruiker kan beoordelen welke gevolgen het wissen van de formules voor hem/haar heeft en hij/zij moet daar dus over ingelicht worden en de mogelijkheid hebben dataverlies te voorkomen. (klik)
Ook de moeite van het lezen waard: klik
Excel representeerd de spreadsheet zoals de verzender hem verzonden heeft en je kunt deze info daarom gewoon gebruiken.
Symphony verminkt gewoon de spreadsheet. Je kunt er dus niks mee.
En dat is een loepzuivere haldraai. Jij doet de volgende bewering:
spreadsheetbestand met niet geelimineerde maar niet door de spreadsheet applicatie herkende formules gaat bewerken is het potentieel meteen corrupt wat dan niet evident is voor de gebruiker.
In welke plaatje is het nu 'evident' dat er iets mis is met de formules?
Keer op keer blijk je niet in staat om een reactie te geven die een logische verhouding heeft tot hetgeen waar je op suggereert te reageren. Het is weer de 'waterval van onzin'.
maar er zijn ook situaties denkbaar waar het verlies vandie formules ernstige gevolgen kan hebben
De risico's zijn veel groter als je niet herkende formules in de spreadsheet laat staan. Dat kan hele enge fouten opleveren omdat de meest basic aan spreadsheet mutaties als het toevoegen van een rij nieuwe corruptie in de spreadsheet veroorzaakt.
In welke plaatje is het nu 'evident' dat er iets mis is met de formules?
Wat is dat voor slappe opmerking. Kun jij ook zien welke formules er allemaal niet in beeld staan. Formules ook prima verbrogen zij voor de gebruiken en kunnen zelfs op achterliggend werkbladen staan.
Verder stelde je eerder nog
Ten eerste hoef je niet noodzakelijkerwijs de formules te deleten om de laatste getalswaarde weer te geven.
Precies een methode om de spreadsheet er uit te laten zien of deze nog normaal werkt ondanks dat de spreadhseet niet worden herkent en terwijl je dan met een miniscule mutatie je spreadsheet kan corrumperen.
Wat is dat voor slappe opmerking. Kun jij ook zien welke formules er allemaal niet in beeld staan.
Jij blijft haldraaien. Jij doet de volgende bewering:
spreadsheetbestand met niet geelimineerde maar niet door de spreadsheet applicatie herkende formules gaat bewerken is het potentieel meteen corrupt wat dan niet evident is voor de gebruiker.
Ik geef een loepzuiver tegenvoorbeeld (klik, klik). In welk plaatje is het nu 'evident' voor de gebruiker dat de formules niet meer werken?
De risico's zijn veel groter als je niet herkende formules in de spreadsheet laat staan.
Volgens jou. Het probleem is echter dat jij dat, net als Excel, niet kunt weten. Alleen de gebruiker kan beoordelen welke gevolgen het wissen van de formules voor hem/haar heeft en hij/zij moet daar dus over ingelicht worden en de mogelijkheid hebben dataverlies te voorkomen (klik).
Je suggeert dat je formules zou kunnen behouden om voor iets te gebruiken. Dat is dus gewoon NIET WAAR !!!
Dat is dus gewoon wel waar, alleen niet met Excel. Microsoft heeft voor haar klanten besloten dat als de formules niet met Excel te gebruiken zijn dat haar klanten die formules dan maar helemaal niet meer nodig hebben. Daar zit hem het probleem (klik).
Nog steeds aan het discuteren? Je snapt toch wel dat DP in dit kringetje doordraait totdat je het moe bent?
Als je een formule niet erkent als informatie binnen een spreadsheet, dan kan je dit eindeloos volhouden. Hoe krom dat argument ook is.
Wat ik wel weet, is dat wanneer ik een Excel sheet zou krijgen, het hele blad knip en vervolgens via speciaal plakken vul met alleen de waardes, ik verschrikkelijk ruzie ga krijgen met meer dan één collega.
Bij DP op het werk is dat klaarblijkelijk niet zo. Ik kan alleen aannemen dat DP's bedrijf kan werken met zeer statische gegevens.
Bij DP op het werk is dat klaarblijkelijk niet zo. Ik kan alleen aannemen dat DP's bedrijf kan werken met zeer statische gegevens.
Je gaat er van uit dat DP eerlijk, of zelfs maar consistent is in zijn reacties. Ik heb daar mijn twijfels over.
Als je een formule niet erkent als informatie binnen een spreadsheet, dan kan je dit eindeloos volhouden. Hoe krom dat argument ook is.
Een goed interpreteerbare formule kan alleen bijdragen tot informatie in een spreadsheet als deze door de spreadsheet volledig herkend wordt.
Een niet herkende formule staat juist in de weg van het tonen van de reeds berekende informatie in het spreadsheet en is een recept voor corruptie bij mutaties.
Dat is dus gewoon wel waar, alleen niet met Excel. Microsoft heeft voor haar klanten besloten dat als de formules niet met Excel te gebruiken zijn dat haar klanten die formules dan maar helemaal niet meer nodig hebben
Andere spreadsheet applicaties herkennen ook de OpenOffice spreasheet formules niet. Deze tonen de niet herkende formules maar als je in deze applicaties de spreadsheet aanpast is er een grote kan op corruptie.
Telkenmlae wordt dit genegeerd. Niet herkende spreadsheet formules in een spreadsheet zijn geen informatie maar een recept om je spreadsheet te corrumperen (als die al niet corrupt is). Dat is echt het laatste wat je wilt.
Blijkbaar hebben jullie liever corrupte spreadsheets dan spreadsheet met valide data. Een ander uitleg is er niet.
Blijkbaar hebben jullie liever corrupte spreadsheets dan spreadsheet met valide data. Een ander uitleg is er niet.
Nog maar een keer dan. MS heeft er voor gekozen dat Excel de formules uit OOo-spreadsheets niet herkent. Om de boel nog erger te maken verwijdert Excel die formules maar helemaal, en neemt niet eens de moeite om ze tonen. Tonen, doorrekenen, twee heel verschillende zaken. Formules tonen verplicht je niet om ze door te rekenen.
Je legt me woorden in de mond. Dat ben ik van je gewend.
Nee, ik wil geen corrupte spreadsheet. Ik wil een spreadsheet met valide informatie. Alle informatie, dus ook de informatie die ik uit de formules kan halen. Excel vernietigt met het verwijderen van die formules informatie.
Ik herhaal mijn eerder gestelde vraag nog maar eens: hoe staat jouw werkgever tegenover informatievernietiging?
Als je de spreadsheet neit herkent kun je ze niet doorrekenen en zijn ze alleen een blokade in het otnen van de reeds berekende informatie en een bron van corrupte bij edit aan de spreadsheet.
En de OOo spreadhseet niet herkennen is inderdaad iets wat Excel niet kan maar is wel heel heel gebruikelijk want zelfs OpenOffice afgeleiden kunnen standaard OpenOffice spreadsheets niet eens herkennen.
En als je dus de spreadheet formula's niet herkent is het verwijderen en de gebruiker daaroverinformeren een prima oplossing. Zeker beter dan dde nietherkende formules aan willekeurige gebruikers tonen en daarbij de informatieve reeds doorgerekende data uit het zicht van de gebruiker te houden.
Symphony en Excel rekenen beide niet goed meer door, maar in welke plaatje is het nu 'evident' dat er iets mis is met de formules?
Excel representeerd de spreadsheet zoals de verzender hem verzonden heeft en je kunt deze info daarom gewoon gebruiken.
Symphony verminkt gewoon de spreadsheet.
Je kunt er dus niks mee.
Excel representeerd de spreadsheet zoals de verzender hem verzonden heeft en je kunt deze info daarom gewoon gebruiken.
Excel presenteert de spreadsheet zonder formule. De 'info' die in de formule zat is daarmee vernietigd. Info die er niet meer is kun je niet gebruiken.
Ik herhaal mijn vraag: hoe staat jouw werkgever tegenover informatievernietiging? Ik krijg er maar geen antwoord op.
Afgezien van dom geblaat
dan.
Info die er niet meer is kun je niet gebruiken.
Zoals ik al tient keer heb aan gegeven.
Niet herkende formules die er wel in zitten kun je ook niet gebruiken maar maken bovendien bij elke mutatie je spreadsheet potentieel corrupt.
Je suggeert dat je formules zou kunnen behouden om voor iets te gebruiken. Dat is dus gewoon NIET WAAR !!!
Elke mutatie aan een spreadheet met daarin niet herkende formules levert aanzienlijke risico's op verminking van de data.
Daar is in de oplossing van Excel juist geen risico op.
De data is volledig behouden.
Je suggeert dat je formules zou kunnen behouden om voor iets te gebruiken. Dat is dus gewoon NIET WAAR !!!
Toch wel. Alleen heeft MS er voor gekozen om dat niet te doen.
Zelfs als MS stommetje speelt en de formule niet wil doorrekenen dan kan die formule nog steeds getoond worden. Ook daar hebben ze niet voor gekozen.
Ik herhaal mijn vraag nog maar eens: hoe staat jouw werkgever tegenover informatievernietiging? Afgezien vandom geblaat
heb ik daar nog steeds geen antwoord op.
De niet herkende formule tonen is zinloos.
Je wilt juist het resultaat van de formule zien. Dat is namelijk de informatie die je wilt hebben in een spreadsheet.
En als iemand een spreadsheet met niet herkende formules erin gaat zitten editten is de kans groot dat deze volslagen corrupt wordt.
De niet herkende formule tonen is zinloos.
Ik herhaal: de formule is informatie. Jij vindt een niet herkende formule op voorhand waardeloos, maar dat oordeel is aan de maker en de ontvanger. In veel gevallen is dat iemand anders dan jij, dosprompt. Bijna altijd, om helemaal eerlijk te zijn. Tenzij MS een telepathie-plugin voor Excel heeft onwikkeld is het onmogelijk dat Excel de bedoelingen van de maker van een spreadsheet kan weten.
Je wilt juist het resultaat van de formule zien. Dat is namelijk de informatie die je wilt hebben in een spreadsheet.
Ik herhaal mijn vraag nog maar eens: hoe staat jouw werkgever tegenover informatievernietiging?
Van informatievernietiging zou sprake zijn als je de info had. Niet herkende spreadsheet formules zijn geen info maar ballast die je berekende informatie verbergen en je spreadsheet kunnen beschadigen.
Niet herkende spreadsheet formules zijn geen info maar ballast
Omdat MS er voor heeft gekozen dat Excel die formules niet herkent kan Excel er niks mee.
Er is geen wet die ze die keus opdringt, dat was uit vrije wil. Net zoals MS ervoor gekozen heeft om de formule helemaal weg te gooien.
Ik herhaal mijn vraag: hoe staat jouw werkgever tegenover informatie-vernietiging?
Omdat MS er voor heeft gekozen dat Excel die formules niet herkent kan Excel er niks mee.
Welke variant bedoel je nu ? De propriety OOo 2.x formules of de draft versie van Openformual die nu in OpenOffice.org wordt gebruikt? Of had Excel die alletwee maar even moeten opndersteunen ????
De oorzaak ligt niet bij excel maar bij ODF een standaard is waarmee geen formules gedefinieerd zijn.
En ook allerlei OOo klonen kunnen niks met OOo spreadsheetformules omdat ze die niet herkennen
En OOo zelf kan bijvoorbeeld weer niks met de Excel based spreadsheet (een ISO based open standaard) terwijl die nieuwe Excel ODF files wel al door KOffice en Gnome Office wel worden herkend.
Verder laat dat onverlet dat als een spreadsheet de formules niet herkend en wel beschikt over berekende waardes dat het verstandig is om deze berekende waardes te gebruiken en de formules te dumpen zodat deze niet de spreadsheet kunne corrumperen bij het editten (en saven).
ik ben lui en kijk even alleen naar de data die jij linkt.
In symphony zie ik een zinloze formule zonder enige uitkomst.
In excel zie ik geen formule maar wel op het oog kloppende data die betekenisvol is.
Wat vond jij de beste benadering?
ik ben lui en kijk even alleen naar de data die jij linkt. In symphony zie ik een zinloze formule zonder enige uitkomst. In excel zie ik geen formule maar wel op het oog kloppende data die betekenisvol is.
In welk plaatje is het 'evident' dat de formules niet meer werken? In het plaatje met de 'zinloze formule zonder enige uitkomst' of in het plaatje met de op het 'oog kloppende data die betekenisvol is'?
In welke plaatje is het nu 'evident' dat er iets mis is met de formules?
Wat vond jij de beste benadering?
Ik ben lui en verwijs je voor het antwoord op die vraag even terug naar mijn voorgaande reacties: klik, klik, klik, klik, klik, klik, klik
Bij het plaatje met de kloppende data heeft MS vooraf de gebruikers geinformeerd dat alle formules uit het document zijn verwijderd. Daarmee is de situatie van de data precies duidelijk. In de spreadsheet met de nietherkende formules is er nog nauwelijk sprake van zinvolle data.
Ten eerste kan het ook zijn dat de gebruiker de spreadsheet niet nog gaat bewerken, in die situatie heb je dan sowieso dataverlies vermeden
goh, dan heb je inderdaad ook gewoon het originele bestand nog.
En zodra je een spreadsheetbestand met niet geelimineerde maar niet door de spreadsheet applicatie herkende formules gaat bewerken is het potentieel meteen corrupt wat dan niet evident is voor de gebruiker.
Die welk compatibel moet zijn en dus langere test voor nodig is. En goed testen kost nu eenmaal veel tijd.
@Dosprompt
Nu je over online en abbo schrijft, weet jij iets over dat cloudcomputing van microsoft. Ze schreven een tijd geleden in de pers over grote datacenters opzetten t.b.v. dienstverlening. Daarna nooit meer iets van vernomen.
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
